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

2014-08-08 Por tôpico Samir Cury
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

2014-08-08 Por tôpico Renato Santos
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

2014-08-08 Por tôpico Rodrigo Mosconi (perl)
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

2014-08-08 Por tôpico Renato Santos
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

2014-08-08 Por tôpico 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 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