[Rio-pm] Modulo - dependencias em pacotes do sistema

[Blabos de Blebe]

Opa,

> Mas me deixa nervoso ter algo no CPAN que nao seria instalado
perfeitamente pelo
> CPAN na distribuicao padrao. Tenho quase certeza que o maximo que posso
fazer
> e deixar um warning gigante no POD, mas queria conferir com voces.

Isso (nervoso) não faz sentido e eu vou tentar clarificar o porquê.

Vários módulos são wrappers em Perl para bibliotecas que não fazem parte da
distribuição padrão, portanto, não faz sentido, querer o módulo, sem ter a
biblioteca.

Aliás, a biblioteca não estar instalada na distribuição padrão é análoga ao
módulo não estar no core do Perl.

Então é natural que alguns módulos não core, esperem ter disponível uma
biblioteca "não core" da distribuição.

lalala-lib X lalala-lib-dev
==================

Quando essa integração com bibliotecas externas acontece, é necessário um
pouco de cola em XS, que nada mais é do que um "C com esteróides".

Esse XS precisa ser compilado durante a instalação do módulo. Por quê?
Porque sendo código C que vai virar binário, ele precisa ser exatamente
compatível com os binários específicos (*.so/*.a) que você você tem na sua
máquina. Coisas de build/linking, podemos detalhar mais em outra ocasião.

Para compilar o XS, você vai precisar dos arquivos de cabeçalho em C (*.h),
bem como do compilador e ferramentas conjuntas. Esses arquivos avisam pro
compilador, qual a assinatura das funções da lib externa que você está
usando. Como eles são usados somente na compilação, eles são distribuídos
em separado em pacotes lalala-lib-dev.

Já o seu módulo, depois de compilado, vai usar os binários da biblioteca e
não vai estar nem aí mais pros cabeçalhos.

O triste aqui é que quando você está falando de pacotes que são
distribuídos de forma binária, vc pode pré-compilar e empacotar as libs sem
os cabeçalhos. Mas quando você está falando de módulo Perl que precisa
rodar em mais de 90 arquiteturas, o que for em XS precisa ser compilado
especificamente para aquela máquina.

O que normalmente acontece é que os módulos mais famosos costumam ter um
padrinho, que os compila para as principais arquiteturas onde a
distribuição linux roda e por isso vc consegue instala-los com yum ou
apt-get.

Como isso dá um trabalho do cacete, nem todos os módulos tem pacotes da
distro, e normalmente eles não são as versões mais atualizadas.

Lembro-me que uma vez o Solli tinha pensado em fazer algo a respeito, mas
não sei o que deu dessa história. Só sei que o trabalho pra manter os
milhares de módulos do CPAN com um pacote atualizado pra cada distro e pra
cada arquitetura deve ser gigantesco.

Samir,

Acredito que pro seu caso, como é só um módulo, vc possa montar um pacote
para principais distros/arquiteturas colocando as libs externas como
dependência. Talvez nem dê tanto trabalho assim.

Assim, quando alguém der apt-get seu-modulo, o próprio apt-get vai baixar
as bibliotecas necessárias, sem precisar dos lalala-lib-dev, já que ele já
vai estar compilado.

Ou então usar a sugestão do Cron mesmo.

Essa eu nunca tentei. Ok, nunca tentei nenhuma das duas :)

Tá aí um bom tema para uma apresentação num ET ou YAPC da vida.



[]'s


2014-08-08 15:28 GMT-03:00 Renato Santos <renato.cron em gmail.com>:

> Hm
> acho que você procura algo sobre isso:
> https://metacpan.org/pod/Alien
>
>
> 2014-08-08 15:14 GMT-03:00 Samir Cury <samircurys em gmail.com>:
>
>> Perlssoal,
>>
>> Estou testando como um modulo que escrevi instala em um CentOS 6 puro,
>> para que no fim eu me livre do selo "works on my machine".
>>
>> Percebi que o CPAN vai sofrer um pouco se nao houver "expat-devel" e
>> "gcc" instalados no sistema. Pode-se argumentar que e fora do escopo do
>> CPAN, resolver problemas como este.
>>
>> O que me faz sentir falta do Slackware, que ja vinha bem completo e era
>> so alegria.
>>
>> O que pensei em fazer e um RPM para o Fedora/CentOS que contem estas
>> dependencias. Beleza, dai o cara pode usar yum install perl-package-name ou
>> yum install 'perl(Package::Name)'.
>>
>> Mas me deixa nervoso ter algo no CPAN que nao seria instalado
>> perfeitamente pelo CPAN na distribuicao padrao. Tenho quase certeza que o
>> maximo que posso fazer e deixar um warning gigante no POD, mas queria
>> conferir com voces.
>>
>> Se precisarem, o modulo e HTCondor::Queue::Parser. Por acidente achei o
>> report no CPAN Testers, que parece bem tranquilo :
>>
>>
>> http://www.cpantesters.org/distro/H/HTCondor-Queue-Parser.html?oncpan=1&distmat=1&version=0.04
>>
>> Talvez o ambiente deles ja resolve esses problemas. Mas por
>> perfeccionismo quero que o modulo instale sem problemas no CentOS padrao.
>>
>> Abracos,
>> Samir
>>
>>
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>
>
>
> --
> Saravá,
> Renato CRON
> http://www.renatocron.com/blog/
> @renato_cron <http://twitter.com/#!/renato_cron>
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20140808/9ef316e3/attachment-0001.html>