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.c...@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 <samircu...@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@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@pm.org > http://mail.pm.org/mailman/listinfo/rio-pm >
_______________________________________________ Rio-pm mailing list Rio-pm@pm.org http://mail.pm.org/mailman/listinfo/rio-pm