Por que os pacotes .so são fornecidos pelos pacotes devel?

6

Eu vi um padrão interessante em embalagens RPM. O pacote principal da biblioteca incluirá a própria biblioteca compartilhada:

/usr/lib64/libavcodec.so.54

O pacote -devel fornecerá cabeçalhos e um link simbólico:

/usr/include/libavcodec/libavcodec.h
/usr/lib64/libavcodec.so -> /usr/lib64/libavcodec.so.54

Por que o link simbólico libavcodec.so é fornecido pelo pacote devel e não está incluído apenas no pacote da biblioteca compartilhada? O que sobre o link simbólico tem algo a ver com algo que um desenvolvedor iria querer? Os cabeçalhos fazem sentido, mas por que o link simbólico para o objeto compartilhado?

    
por Naftuli Kay 22.01.2016 / 03:27

2 respostas

8

O software da distribuição é mecanicamente vinculado de forma consistente e espera encontrar libavcodec.so.54 , portanto, o nome não versionado não é necessário para nenhum dos pacotes pré-criados.

Se você mesmo criar software, é comum usar -lavcodec ou similar, que encontrará libavcodec.so sem versão. Da mesma forma, os scripts de construção podem esperar que esses nomes existam.

Os nomes não versionados não são necessários para os pacotes de distribuição, portanto, eles não são incluídos por padrão, mas como são úteis ao criar outros softwares, eles são incluídos no pacote -devel . Outras distribuições fazem delineações diferentes e incluem o link .so no pacote principal; ambas são escolhas razoáveis.

    
por 22.01.2016 / 03:36
-2

Existem diferentes maneiras de lidar com isso, mas, em geral, não precisaria ser manipulado se você não usasse o gerenciamento de pacotes automatizado. Na verdade, a maioria do trabalho feito pelos gerenciadores de pacotes automatizados é feito apenas para corrigir problemas causados pelo gerenciamento automatizado de pacotes. Isso não significa que não exista qualquer valor nos gerenciadores de pacotes, apenas que o valor agregado é caro em termos de sobrecorreção necessária após o fato.

Quando você estabelece um método de gerenciamento de pacotes, você se tranca nele. Você dá o controle do seu rootfs para algum esquema ou outro, e suas excentricidades são algo que você tem que aceitar a partir desse ponto, porque depois disso qualquer Um arquivo pode ser codependente em qualquer outro arquivo e a única maneira de saber é desvendar toda a web até que você possa ver a parte inferior.

Os gerenciadores de pacotes interligam a web, entre e sobre os encadeamentos da biblioteca vinculados dinamicamente. Normalmente, as soluções de gerenciamento de pacotes dependem muito de links dinâmicos - o que torna mais fácil para os gerentes de pacotes controlarem a versão se um conjunto inteiro de aplicativos puder originar a mesma biblioteca. E onde os gerenciadores de pacotes diferem principalmente em suas várias estratégias para lidar com o versionamento de bibliotecas dinâmicas - especialmente em um ambiente FHS porque a raiz A árvore é realmente a única outra grande parte variável do quebra-cabeça. Você apontou um desses típicos de apt -based schema s.

    
por 22.01.2016 / 04:16