Iniciar sessão

Navegação

Votação

Gestor de Pacotes

apt-get

36%

aptitude

45%

dselect

synaptic

outro?

Votos totais: 11

Clique Iniciar Sessão ou registar-se para colocar comentários
Votações antigas

Latest image

Navegação do livro

Novos utilizadores

Debian Security

mais

Number of feed subscribers

124subscribers

Debian e EGLIBC

Colocado Quarta, 2009-05-06 21:56 por nifan

Certamente que já alguns terão lido esta notícia noutros locais da interweb, por isso juntamo-nos à 'maralha' :)

A notícia chegou-nos pela mão do Aurelien [1].

Neste post, Aurelien, anuncia que efectuou o upload do pacote da Embedded GLIBC (EGLIBC) para o arquivo, sendo que a substituição da GLIBC será substituida rapidamente. Esta decisão terá sido efectuada pelos Mantainers Debian da GLIBC.

Segundo o site do EGLIBC [2] este é uma variante da GLIBC, tendo como objectivo funcionar de forma optimizada em sistemas embebidos. Além disto, pretende ser compatível quer a nível de código fonte quer binário com a GLIBC.

Aurelien apontou diversos pontos que ajudaram na decisão da transição de uma biblioteca para a outra, tais como:

'Upstream' mais sociável, "Encorajar cooperação, comunicação, civismo e respeito entre developers" [3] ao contrário de casos como [4], [5], [6] e [7] .
Branch estável com bugs importantes resolvidos (EGLIBC usa SVN enquanto que GLIBC ainda usa CVS, apesar de na próxima versão estar prevista a mudança para o git [8])
Melhor suporte para arquitecturas embebidas.
Suporte para diferentes shells - (GLIBC só suporta bash [9] [10]).
Suporte à compilação com -Os (Para quem não sabe, esta flag do GCC permite optimizar os binários compilados para o tamanho, importantes no mundo dos sistemas embebidos).
Componentes configuráveis (o NIS e o RPC não são realmente necessários no debian-installer).
Uma melhor testsuite para pacotes optimizados ou com múltiplas arquitecturas.

Segundo o autor do artigo, Debian ainda não aproveita todas estas funcionalidades, mas que este é apenas um primeiro passo nesse sentido.

Este movimento lembra-me bastante o que ocorreu com o cdrtools e o seu programador Jörg Schilling, cujo mau-feitio levou ao aparecimento do wodim como fork, bem como da saga Xfree86 para o fork Xorg. O programador da GLIBC (que trabalha para a Red Hat), de nome Ulrich Drepper, também não é conhecido pela sua simpatia, havendo diversos casos disso mesmo no Bugzilla da GLIBC. Um anterior DPL (Sam Hocevar) viu-se numa ocasião obrigado a pedir a intervenção do GNU C Library Steering Committee devido a atritos entre Drepper e os mantainers de arquitecturas embedidas suportadas pelo projecto [11].

Por outro lado, apareceu de imediato alguma renitência nesta mudança, já que apesar de a EGLIBC tentar sempre que possível manter-se compatível com a GLIBC, poderá haver situações em que seja necessário haver alterações no código fonte dos programas para que possam correr sem problemas.
Outros argumentam que esperam que os programadores da EGLIBC sejam abertos quanto à posibilidade de incluir algumas funções importantes, nomeadamente strlcpy e strlcat, que se pretendem mais seguras e consistentes [12], ao passo que outros afirmam que a adição de funções destrói o propósito de se manter compatível (iria quebrar a compatibilidade ABI) com a GLIBC (devo lembrar que a EGLIBC não é um verdadeiro fork, isto é, possui um código fonte à parte mas frequentemente são feitos 'syncs' com a GLIBC). Por outro lado, a funcionalidade da strlcpy e strlcat podem ser obtidas com bibliotecas tais como a libbsd e a ustr.

Como defesa de Drepper podemos argumentar que mantém muitos outros projectos, e o seu mau feitio seja uma forma de demonstrar que não tem tempo para tudo.

Esperam-se mais episódios desta novela :)
Endereços: