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

2014-08-08 Por tôpico Renato Santos 
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"  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 :
>
>> 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 :
>>
>>> Hm
>>> acho que você procura algo sobre isso:
>>> https://metacpan.org/pod/Alien
>>>
>>>
>>> 2014-08-08 15:14 GMT-03:00

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 :

> 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 :
>
> Hm
>> acho que você procura algo sobre isso:
>> https://metacpan.org/pod/Alien
>>
>>
>> 2014-08-08 15:14 GMT-03:00 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

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) :

>
>
>
> Em 8 de agosto de 2014 15:14, Samir Cury  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=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
>>
>>
> 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 
___
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  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=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
>
>
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 Blabos de Blebe 
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 :

> Hm
> acho que você procura algo sobre isso:
> https://metacpan.org/pod/Alien
>
>
> 2014-08-08 15:14 GMT-03:00 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=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 
>
> ___
> 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 :

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

[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=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