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

Sexta Agosto 8 19:07:31 PDT 2014

Então, o Alien é para o processo inverso, onde você vai executar o cpan
nome::seu:módulo aí o seu modelo que ficará responsável por instalar as
deps binárias (o que faz necessário a maquina ter, no mínimo, make e um
compilador).

É trabalhoso demais instalar as deps, é mais simples gerar o binário para a
distribuição desejada, geralmente.

É um mundo complicado esse que vivemos!
On Aug 8, 2014 11:01 PM, "Samir Cury" <samircurys em gmail.com> wrote:
>
> 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
>>>
>>> _______________________________________________
>>> 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
>
>
>
> _______________________________________________
> 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/e12ce6a8/attachment.html>