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