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

[Samir Cury]

Obrigado pelas respostas, bastante informacao util.

Achei bem interessante o lance do Alien. Vou olhar com mais calma depois. A
principio, resolveria o problema.

Apesar de concordar com o Blabos em varios pontos, ainda acho que pra quem
nao liga ou nao se importa com Perl, CPAN, etc, vai simplesmente dizer "ah,
esse troco nao funciona". E exatamente isso que quero evitar, atitude que
infelizmente tenho visto cada vez mais devido as tendencias da galera
considerar varias coisas como caixas pretas, ao inves de perder 3~5 min
descobrindo o problema.

Sobre RPMs, chega a ser quase trivial, uma vez que se acostuma. Acho que o
que vai dar mais trabalho e a burocracia de incluir o RPM no repositorio
Contrib. Lembro que o Debian parecia uma sociedade secreta, so entrava
apadrinhado ou depois de ralar muito, algo assim.

O pacote na distro parece o mais limpo. E como so me importo em dar suporte
ao CentOS (e talvez Debian) pode ser o caminho. Se acontecer algo com o
Alien aviso quanto trabalho deu. Parece ser a solucao mais interessante
porque o CPAN funcionaria sozinho.

Abs




2014-08-08 11:53 GMT-07:00 Blabos de Blebe <blabos em gmail.com>:

> 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
>>
>
>
> _______________________________________________
> 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/cc3e2c0e/attachment-0001.html>