Me interessei especialmente pela idéia número 4, chamada pelo autor de “using symbol versioning information in dpkg-shlibdeps“, ou, abrasileirando, “utilizando informações de versionamento de símbolos no dpkg-shlibdeps”. Com a leitura da idéia básica percebi que tratava-se de algo realmente interessante e poderia ajudar versões novas de softwares empacotados serem instaladas em versõe antigas do Debian sem precisar de backport algum, mas queria confirmar minha suspeita.

Enviei um e-mail ao autor do post, perguntando se o mesmo tinha mais alguma informação sobre o assunto ou alguma referência sobre o mesmo para me indicar. Ele respondeu e deu uma explicação rápida sobre o assunto, em inglês, mas vou traduzí-la abaixo e espero não fazer feio :

Olá,

Você perguntou sobre a idéia “utilizando informações de versionamento de símbolos no dpkg-sh libdeps”.

Bom, eu acho que você já está familiar com o gerenciamento atual, que é obter uma lista de bibliotecas referenciadas de objetos em um pacote executando-se objdump no mesmo, extraíndo as entradas NEEDED e procurando nos arquivos shlibs que estão instalados (e também aqueles do pacote atual).

Até agora, se você referencia libc.so.6, o mecanismo shlibs procura por uma entrada na forma

“libc 6 …”

e insere a parte “…” na variável “shlibs:Depends” para o pacote.

Versões de símbolos por sua vez permitem que uma biblioteca declare que existem diversas versões de um símbolo e qualquer coisa que se lige contra o mesmo especifique a qual versão se referem. Normalmente, essas versões são obtidas no contexto de toda a biblioteca. Por exemplo, a glibc possui versões para releases maiores (major) e menores (minor) (GLIBC_2_0, GLIBC_2_1 e assim por diante). Caso um símbolo não mude, você não precisa mudar a informação de versionamento também quando lançando uma nova versão de um pacote. Na verdade, a maioria dos símbolos possuem uma versão bastante antiga anexada aos mesmos.

Todos os binários que foram ligados contra a glibc desde a introdução de versões de símbolos possuem uma lista de quais símbolos são necessários (isso é basicamente um atalho para que o ligador (linker) possa decidir procurar nas versões dos símbolos para saber se todos os símbolos necessários estão presentes) de cada biblioteca.

Agora, o que o formorer está implementando é uma maneira de especificar, por exemplo

GLIBC_2_0: libc 6 libc6 (>= 2.0.0)
GLIBC_2_1: libc 6 libc6 (>= 2.1.0)

e assim por diante. Esse formato é compatível com as ferramentas atuais (essas entradas são então ignoradas). Nós geramos uma lista de dependências que precisamos para mesclar para a mais estrita. Caso um binário dependa dos símbolos GLIBC_2_0 e GLIBC_2_1, o resultado seria “libc6 (>= 2.1.0)”, que é uma versão bem antiga. Os binários serão executados normalmente, uma vez que eles não precisam de nada novo, portanto, a especificação de dependência está correta.

O resultado final é que binários compilados dessa forma não precisarão ser backportados, uma vez que eles já podem ser instalados sem problemas em releases mais antigos.

Caso você tenha mais perguntas, pergunte.

Simon

Entenderam a idéia ? Se isso realmente funcionar, esqueça o trabalho que sempre temos ao precisar recompilar pacotes mais novos em um release antigo somente para que as versões corretas sejam substituídas corretamente em “shlibs:Depends“.

Como ele exemplificou, o caso da glibc é clássico. Eu mesmo já cansei de me deparar com casos em que eu precisava de uma versão mais nova de um software já empacotada na unstable e só não consegui simplesmente pegar o pacote da unstable e simplesmente instalá-lo na stable porque as informações de dependência estavam infladas, visto que o pacote havia sido gerado em um ambiente de compilação unstable.
Com o sistema de shlibs realmente indo a fundo e cavando exatamente qual versão de cada símbolo é necessária, as chances de podermos utilizar pacotes Debian feitos para um release (entenda-se distribuição, nesse caso) mais novo em um release mais antigo são bastante altas.

Isso iria diminuir muito o trabalho do pessoal do backports.org, por exemplo, e facilitar a vida de muitos administradores de sistema. Ah ! E sabe o formorer que ele citou ? É mais um desenvolvedor Debian, Alexander Wirt, que, segundo ele, já está trabalhando em uma reescrita do dpkg-shlibdeps que vai trazer essa nova funcionalidade ao utilitário.

Ok, isso seria um bom banho de água fria diretamente na cabeça daqueles que dizem que o Debian não inova. Talvez não tenhamos as versões mais novas de todos os softwares sempre (mas mesmo isso é questionável), mas mudanças profundas e realmente úteis como essas são uma prova de que o Debian está interessado em fazer as coisas da forma correta e não criar retalhos.