[Rio-pm] Modulo - dependencias em pacotes do sistema
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=1distmat=1version=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
Re: [Rio-pm] Modulo - dependencias em pacotes do sistema
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=1distmat=1version=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
Re: [Rio-pm] Modulo - dependencias em pacotes do sistema
Em 8 de agosto de 2014 15:14, Samir Cury samircu...@gmail.com escreveu: 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=1distmat=1version=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 Os módulos Perl provenientes do CPAN podem ser obtidos pela ferramentas cpanspec ou cpan2rpm. A primeira gera o arquivo .spec que permitirá a criação dos RPM e SRPM. A segunda não cheguei a usar/testar. ___ 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
Re: [Rio-pm] Modulo - dependencias em pacotes do sistema
Ah, Este jeito que vou contar abaixo, não é recomendavel para ĩnstalações de modulos (afinal, você vai querer que seu modulo seja instalado ao lado dos outros, e não levar o codigo de mais um monte de modulos juntos ao seu), mas funciona para distribuir aplicativos. O Thiago (maluco) e o Gabriel (gabiruh) criaram um jeito legal para distribuir a versão linux do agente da b-datum, e todo o código está aberto em: https://github.com/b-datum/b-datum-linux Eu sei que ele usa o https://metacpan.org/pod/App::FatPacker para pegar todos os modulos que não são core, mas que são pure-perl, e a partir dai, o fatpacker junta todos os modulos na fatlib, então você pode ter quantos modulos PP você quiser. Mas você ainda tem que cuidar dos modulos que dependem de binarios, e de alguns modulos que alguns OS mudam o arquivo do core do perl (medo) Para os modulos binarios, na hora de montar o .deb por exemplo, você coloca o modulo binario que você precisa, como dependencia. Neste caso, alguem já precisa ter feito a gentiliza de cria-lo para você. https://github.com/b-datum/b-datum-linux/blob/master/linux/b-datum-linux.spec https://github.com/b-datum/b-datum-linux/tree/master/linux/debian https://github.com/b-datum/b-datum-linux/blob/master/macos/com.bdatum.backup.mac.plist Eu não lembro exatamente como ele faz para gerar cada release e soltar no github, mas ai da até pra colocar lá https://github.com/b-datum/b-datum-linux/releases 2014-08-08 22:19 GMT-03:00 Rodrigo Mosconi (perl) p...@mosconi.mat.br: Em 8 de agosto de 2014 15:14, Samir Cury samircu...@gmail.com escreveu: 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=1distmat=1version=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 Os módulos Perl provenientes do CPAN podem ser obtidos pela ferramentas cpanspec ou cpan2rpm. A primeira gera o arquivo .spec que permitirá a criação dos RPM e SRPM. A segunda não cheguei a usar/testar. ___ 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 -- 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
Re: [Rio-pm] Modulo - dependencias em pacotes do sistema
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