Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes

[Blabos de Blebe]

> desci um Debian nele,

Isso. Não Fedora* :)

> depois atualizei o Perl (do sistema), e 'PA' nada aconteceu

Parabéns :)

===

Vejam, não sou sysadmin, então tomem algumas coisas como licença poética:

Eu ia sugerir isso, mas chegou o email do Buss, entao basicamente, por que
não criar um user "Perl", instalar o Perlbrew nele e botar as variáveis de
ambiente no .profile dos usuários?

Aí vc ganha o melhor dos dois mundos. O seu Perl do sistema fica quietinho
sendo administrado pelo yum/apt-get enquanto que o Perl dos usuários fica
atualizadinho sendo administrado por cpanm ou melhor ainda, por Carton,
garantindo que uma vesão nova bugada não vai melar o seu ambiente.

===

* Nenhuma questão quanto a distro em si, apenas por causa do Perl mal
configurado, na época em que eu usava Fedora. Nem sei com está isso hoje em
dia, pra ser sincero.




2014-04-04 16:51 GMT-03:00 Aureliano Guedes :

> Nunca aconselhei atualizar o Perl do sistema, e para garantir minha
> integridade, continuo não aconselhando, mas...
>
> Minhas aplicações não exigem uma 'versão específica' do Perl para serem
> executadas, então uma vez por teste, peguei um pc parado aqui e desci um
> Debian nele, depois atualizei o Perl (do sistema), e 'PA' nada aconteceu
> (digo nada de ruim).
> Não sei quanto a módulos usados pelo sistema, posso fazer esse teste
> depois. Mas não deu problema nenhum.
>
>
> --
> From: bruno.b...@gmail.com
> Date: Fri, 4 Apr 2014 16:35:39 -0300
> To: rio-pm@pm.org
> Subject: Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes
>
>
> Você poderia manter um setup do local::lib/perlbrew que fosse
> compartilhado pelos usuários do seu servidor... não e' porque estamos usado
> algum desses, que precisa ser per-user a instalação de cada um :-)
> Talvez seja necessário configurar algumas variáveis de ambiente pros
> usuários, mas isso não me parece ser um problema muito difícil, certo? ;)
>
> [ ]'s
> Buss
>
> 2014-04-04 16:14 GMT-03:00 Samir Cury :
>
> Interessante.
>
> Agora, se olharmos de um ponto de vista "mais sysadmin" -- voce *quer* que
> os modulos estejam disponiveis system-wide (todos usuarios/ambientes) e nao
> se importa tanto com as versoes especificas dos modulos -- porque a
> principio a maioria das aplicacoes serao compativeis com uma faixa grande
> de versoes de cada modulo.
>
> (acredito que da menos trabalho pensar assim e consertar individualmente o
> que quebrar, do que fazer um bootstrap pra cada aplicacao pra ter certeza
> que "funcionou, nao respira")
>
> Seria o CPAN puro como root ainda sim a melhor opcao neste caso?
>
> Valeu pela dica dos modulos dos pacotes sobre-escritos. Realmente e para
> se considerar. No entanto, nao vejo tanto mal de ter o mesmo modulo
> presente, outra versao. Concordo que e tosco ter "rpm -qa | grep Modulo"
> dizendo uma coisa e quando voce carrega o modulo ser outra.
>
> Quando o RPM for desisntalado deve remover o arquivo, dai o CPAN
> provavelmente vai se perder. Mas enquanto nao remover nada deve ser
> ~tranquilo.
>
> O que estou tentando entender e - qual a melhor maneira de configurar um
> sistema padrao com ferramentas padrao (cpan, rpm, apt). Pelo visto o preco
> de eventuais gambiarras como a que descrevi nao causaria mais problemas do
> que o tempo gasto debugando o teste que nao passou no CPAN. Indesejavel,
> mas nao fatal.
>
> Pelo que entendi no melhor dos mundos -- da instalacao padrao, voce
> escolhe entre 2 caminhos :
>
>   * usa CPAN como root - se um teste quebrar, vai perder um tempo
>   * usa RPMs para tudo - se nao existir um pacote para o modulo, vai ter
> que comecar a "sujar" o sistema com modulos instalados pelo CPAN
>
> E tenta nao misturar.
>
> Abs
>
>
> 2014-04-04 11:48 GMT-07:00 Blabos de Blebe :
>
> Olá,
>
> Normalmente eu evito mexer no Perl do sistema. O fedora, inclusive, é
> historicamente bastante hostil ao lidar com o Perl, diga-se de passagem.
>
> Nos meus projetos, eu procedo da seguinte forma:
>
> 1) Instalar perlbrew*
> 2) Instalar a versão do Perl que eu vou usar**
> 3) Instalar o cpanm (App::cpanminus)
> 4) se máquina de desenvolvimento então
> instalar Carton e Dist::Zilla
> end-se
>
> Daí, para os meus módulos ou aplicações, faço o gerenciamento de pacotes
> com Carton, que me deixa travar a versão exata*** de cada módulo.
>
> Para os módulos não é necessário, mas para as aplicações, o carton permite
> que você empacote todas as dependências em um diretório vendor/, que você
> pode fazer um tar e subir para aquele servidor de produção que não sai pra
> internet, e então instalar normalmente, de forma que mesmo pacotes com XS
> funcionem. O carton se empacotes junto, inclusive, para o caso da máquina
> destino não ter carton instalado.
>
> Assim eu tenho o controle exato de cada versão de cada pacote.
>
> O CPAN é fantástico, sempre foi, mas eu diria que dá pra dividi-lo em duas
> eras: antes e depois do Carton.
>
>
>
> * Curiosamente hoje, a instalação do Perlbrew falhou num debian 6 que eu
> to 

Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes

[Aureliano Guedes]

Nunca aconselhei atualizar o Perl do sistema, e para garantir minha 
integridade, continuo não aconselhando, mas...
Minhas aplicações não exigem uma 'versão específica' do Perl para serem 
executadas, então uma vez por teste, peguei um pc parado aqui e desci um Debian 
nele, depois atualizei o Perl (do sistema), e 'PA' nada aconteceu (digo nada de 
ruim).Não sei quanto a módulos usados pelo sistema, posso fazer esse teste 
depois. Mas não deu problema nenhum. 
From: bruno.b...@gmail.com
Date: Fri, 4 Apr 2014 16:35:39 -0300
To: rio-pm@pm.org
Subject: Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes

Você poderia manter um setup do local::lib/perlbrew que fosse compartilhado 
pelos usuários do seu servidor... não e' porque estamos usado algum desses, que 
precisa ser per-user a instalação de cada um :-)


Talvez seja necessário configurar algumas variáveis de ambiente pros usuários, 
mas isso não me parece ser um problema muito difícil, certo? ;)
[ ]'s

Buss

2014-04-04 16:14 GMT-03:00 Samir Cury :


Interessante.
Agora, se olharmos de um ponto de vista "mais sysadmin" -- voce *quer* que os 
modulos estejam disponiveis system-wide (todos usuarios/ambientes) e nao se 
importa tanto com as versoes especificas dos modulos -- porque a principio a 
maioria das aplicacoes serao compativeis com uma faixa grande de versoes de 
cada modulo. 



(acredito que da menos trabalho pensar assim e consertar individualmente o que 
quebrar, do que fazer um bootstrap pra cada aplicacao pra ter certeza que 
"funcionou, nao respira")



Seria o CPAN puro como root ainda sim a melhor opcao neste caso?
Valeu pela dica dos modulos dos pacotes sobre-escritos. Realmente e para se 
considerar. No entanto, nao vejo tanto mal de ter o mesmo modulo presente, 
outra versao. Concordo que e tosco ter "rpm -qa | grep Modulo" dizendo uma 
coisa e quando voce carrega o modulo ser outra. 



Quando o RPM for desisntalado deve remover o arquivo, dai o CPAN provavelmente 
vai se perder. Mas enquanto nao remover nada deve ser ~tranquilo.
O que estou tentando entender e - qual a melhor maneira de configurar um 
sistema padrao com ferramentas padrao (cpan, rpm, apt). Pelo visto o preco de 
eventuais gambiarras como a que descrevi nao causaria mais problemas do que o 
tempo gasto debugando o teste que nao passou no CPAN. Indesejavel, mas nao 
fatal.



Pelo que entendi no melhor dos mundos -- da instalacao padrao, voce escolhe 
entre 2 caminhos :
  * usa CPAN como root - se um teste quebrar, vai perder um tempo  * usa RPMs 
para tudo - se nao existir um pacote para o modulo, vai ter que comecar a 
"sujar" o sistema com modulos instalados pelo CPAN



E tenta nao misturar.
Abs

2014-04-04 11:48 GMT-07:00 Blabos de Blebe :



Olá,

Normalmente eu evito mexer no Perl do sistema. O fedora, inclusive, é 
historicamente bastante hostil ao lidar com o Perl, diga-se de passagem.





Nos meus projetos, eu procedo da seguinte forma:
1) Instalar perlbrew*2) Instalar a versão do Perl que eu vou usar**3) Instalar 
o cpanm (App::cpanminus)4) se máquina de desenvolvimento então




instalar Carton e Dist::Zillaend-se
Daí, para os meus módulos ou aplicações, faço o gerenciamento de pacotes com 
Carton, que me deixa travar a versão exata*** de cada módulo.





Para os módulos não é necessário, mas para as aplicações, o carton permite que 
você empacote todas as dependências em um diretório vendor/, que você pode 
fazer um tar e subir para aquele servidor de produção que não sai pra internet, 
e então instalar normalmente, de forma que mesmo pacotes com XS funcionem. O 
carton se empacotes junto, inclusive, para o caso da máquina destino não ter 
carton instalado.





Assim eu tenho o controle exato de cada versão de cada pacote.
O CPAN é fantástico, sempre foi, mas eu diria que dá pra dividi-lo em duas 
eras: antes e depois do Carton.







* Curiosamente hoje, a instalação do Perlbrew falhou num debian 6 que eu to 
configurando e eu precisei instalar o pacote Devel::PatchPerl diretamente no 
sistema com o cpan tradicional (root).





** O drawback é que eu preciso de acesso ao compilador.
*** Sim, raramente acontece, mas eu já precisei achar uma combinação X de 
versões pra funcionar redondo, mas nada além de editar o cpanfile e rodar 
carton install denovo.





[]'s

2014-04-04 15:24 GMT-03:00 Samir Cury :





E ai pessoal,
Acabei de passar por um pequeno problema com o CPAN e achei uma solucao 
interessante. Tambem gostaria de perguntar ao pessoal que e mais fa do CPAN, o 
que acham de modulos que sao distribuidos como pacotes. Se e bom/ruim para o 
ecossistema.






Entao, o problema foi quando tentei cpan install CouchDB::Client. Que funcionou 
em outras maquinas mas nao no Fedora 19 que tenho aqui. Quebrou em algum modulo 
referente a testes, que dependia do Module::Build que tambem falhou.






Nao querendo gastar muito tempo com isso, fui para o plano B : Pacotes de 
modulos. O motivo dos pacotes serem meu plano B e que cada distribuicao gos

Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes

[Renato Santos]

Samir, o problema não é um teste seu quebrar, isso seria bom!

Ruim é quando algo do sistema feito em perl quebra, e você só vai saber
disso quando o SO bootar pela metade, num caso ruim.


2014-04-04 16:35 GMT-03:00 Bruno Buss :

> Você poderia manter um setup do local::lib/perlbrew que fosse
> compartilhado pelos usuários do seu servidor... não e' porque estamos usado
> algum desses, que precisa ser per-user a instalação de cada um :-)
> Talvez seja necessário configurar algumas variáveis de ambiente pros
> usuários, mas isso não me parece ser um problema muito difícil, certo? ;)
>
> [ ]'s
> Buss
>
> 2014-04-04 16:14 GMT-03:00 Samir Cury :
>
>> Interessante.
>>
>> Agora, se olharmos de um ponto de vista "mais sysadmin" -- voce *quer*
>> que os modulos estejam disponiveis system-wide (todos usuarios/ambientes) e
>> nao se importa tanto com as versoes especificas dos modulos -- porque a
>> principio a maioria das aplicacoes serao compativeis com uma faixa grande
>> de versoes de cada modulo.
>>
>> (acredito que da menos trabalho pensar assim e consertar individualmente
>> o que quebrar, do que fazer um bootstrap pra cada aplicacao pra ter certeza
>> que "funcionou, nao respira")
>>
>> Seria o CPAN puro como root ainda sim a melhor opcao neste caso?
>>
>> Valeu pela dica dos modulos dos pacotes sobre-escritos. Realmente e para
>> se considerar. No entanto, nao vejo tanto mal de ter o mesmo modulo
>> presente, outra versao. Concordo que e tosco ter "rpm -qa | grep Modulo"
>> dizendo uma coisa e quando voce carrega o modulo ser outra.
>>
>> Quando o RPM for desisntalado deve remover o arquivo, dai o CPAN
>> provavelmente vai se perder. Mas enquanto nao remover nada deve ser
>> ~tranquilo.
>>
>> O que estou tentando entender e - qual a melhor maneira de configurar um
>> sistema padrao com ferramentas padrao (cpan, rpm, apt). Pelo visto o preco
>> de eventuais gambiarras como a que descrevi nao causaria mais problemas do
>> que o tempo gasto debugando o teste que nao passou no CPAN. Indesejavel,
>> mas nao fatal.
>>
>> Pelo que entendi no melhor dos mundos -- da instalacao padrao, voce
>> escolhe entre 2 caminhos :
>>
>>   * usa CPAN como root - se um teste quebrar, vai perder um tempo
>>   * usa RPMs para tudo - se nao existir um pacote para o modulo, vai ter
>> que comecar a "sujar" o sistema com modulos instalados pelo CPAN
>>
>> E tenta nao misturar.
>>
>> Abs
>>
>>
>> 2014-04-04 11:48 GMT-07:00 Blabos de Blebe :
>>
>> Olá,
>>>
>>> Normalmente eu evito mexer no Perl do sistema. O fedora, inclusive, é
>>> historicamente bastante hostil ao lidar com o Perl, diga-se de passagem.
>>>
>>> Nos meus projetos, eu procedo da seguinte forma:
>>>
>>> 1) Instalar perlbrew*
>>> 2) Instalar a versão do Perl que eu vou usar**
>>> 3) Instalar o cpanm (App::cpanminus)
>>> 4) se máquina de desenvolvimento então
>>> instalar Carton e Dist::Zilla
>>> end-se
>>>
>>> Daí, para os meus módulos ou aplicações, faço o gerenciamento de pacotes
>>> com Carton, que me deixa travar a versão exata*** de cada módulo.
>>>
>>> Para os módulos não é necessário, mas para as aplicações, o carton
>>> permite que você empacote todas as dependências em um diretório vendor/,
>>> que você pode fazer um tar e subir para aquele servidor de produção que não
>>> sai pra internet, e então instalar normalmente, de forma que mesmo pacotes
>>> com XS funcionem. O carton se empacotes junto, inclusive, para o caso da
>>> máquina destino não ter carton instalado.
>>>
>>> Assim eu tenho o controle exato de cada versão de cada pacote.
>>>
>>> O CPAN é fantástico, sempre foi, mas eu diria que dá pra dividi-lo em
>>> duas eras: antes e depois do Carton.
>>>
>>>
>>>
>>> * Curiosamente hoje, a instalação do Perlbrew falhou num debian 6 que eu
>>> to configurando e eu precisei instalar o pacote Devel::PatchPerl
>>> diretamente no sistema com o cpan tradicional (root).
>>>
>>> ** O drawback é que eu preciso de acesso ao compilador.
>>>
>>> *** Sim, raramente acontece, mas eu já precisei achar uma combinação X
>>> de versões pra funcionar redondo, mas nada além de editar o cpanfile e
>>> rodar carton install denovo.
>>>
>>> []'s
>>>
>>>
>>> 2014-04-04 15:24 GMT-03:00 Samir Cury :
>>>
 E ai pessoal,

 Acabei de passar por um pequeno problema com o CPAN e achei uma solucao
 interessante. Tambem gostaria de perguntar ao pessoal que e mais fa do
 CPAN, o que acham de modulos que sao distribuidos como pacotes. Se e
 bom/ruim para o ecossistema.

 Entao, o problema foi quando tentei cpan install CouchDB::Client. Que
 funcionou em outras maquinas mas nao no Fedora 19 que tenho aqui. Quebrou
 em algum modulo referente a testes, que dependia do Module::Build que
 tambem falhou.

 Nao querendo gastar muito tempo com isso, fui para o plano B : Pacotes
 de modulos. O motivo dos pacotes serem meu plano B e que cada distribuicao
 gosta de um nome diferente e as vezes e irritante ter que adivinhar, mas
 acab

Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes

[Bruno Buss]

Você poderia manter um setup do local::lib/perlbrew que fosse compartilhado
pelos usuários do seu servidor... não e' porque estamos usado algum desses,
que precisa ser per-user a instalação de cada um :-)
Talvez seja necessário configurar algumas variáveis de ambiente pros
usuários, mas isso não me parece ser um problema muito difícil, certo? ;)

[ ]'s
Buss

2014-04-04 16:14 GMT-03:00 Samir Cury :

> Interessante.
>
> Agora, se olharmos de um ponto de vista "mais sysadmin" -- voce *quer* que
> os modulos estejam disponiveis system-wide (todos usuarios/ambientes) e nao
> se importa tanto com as versoes especificas dos modulos -- porque a
> principio a maioria das aplicacoes serao compativeis com uma faixa grande
> de versoes de cada modulo.
>
> (acredito que da menos trabalho pensar assim e consertar individualmente o
> que quebrar, do que fazer um bootstrap pra cada aplicacao pra ter certeza
> que "funcionou, nao respira")
>
> Seria o CPAN puro como root ainda sim a melhor opcao neste caso?
>
> Valeu pela dica dos modulos dos pacotes sobre-escritos. Realmente e para
> se considerar. No entanto, nao vejo tanto mal de ter o mesmo modulo
> presente, outra versao. Concordo que e tosco ter "rpm -qa | grep Modulo"
> dizendo uma coisa e quando voce carrega o modulo ser outra.
>
> Quando o RPM for desisntalado deve remover o arquivo, dai o CPAN
> provavelmente vai se perder. Mas enquanto nao remover nada deve ser
> ~tranquilo.
>
> O que estou tentando entender e - qual a melhor maneira de configurar um
> sistema padrao com ferramentas padrao (cpan, rpm, apt). Pelo visto o preco
> de eventuais gambiarras como a que descrevi nao causaria mais problemas do
> que o tempo gasto debugando o teste que nao passou no CPAN. Indesejavel,
> mas nao fatal.
>
> Pelo que entendi no melhor dos mundos -- da instalacao padrao, voce
> escolhe entre 2 caminhos :
>
>   * usa CPAN como root - se um teste quebrar, vai perder um tempo
>   * usa RPMs para tudo - se nao existir um pacote para o modulo, vai ter
> que comecar a "sujar" o sistema com modulos instalados pelo CPAN
>
> E tenta nao misturar.
>
> Abs
>
>
> 2014-04-04 11:48 GMT-07:00 Blabos de Blebe :
>
> Olá,
>>
>> Normalmente eu evito mexer no Perl do sistema. O fedora, inclusive, é
>> historicamente bastante hostil ao lidar com o Perl, diga-se de passagem.
>>
>> Nos meus projetos, eu procedo da seguinte forma:
>>
>> 1) Instalar perlbrew*
>> 2) Instalar a versão do Perl que eu vou usar**
>> 3) Instalar o cpanm (App::cpanminus)
>> 4) se máquina de desenvolvimento então
>> instalar Carton e Dist::Zilla
>> end-se
>>
>> Daí, para os meus módulos ou aplicações, faço o gerenciamento de pacotes
>> com Carton, que me deixa travar a versão exata*** de cada módulo.
>>
>> Para os módulos não é necessário, mas para as aplicações, o carton
>> permite que você empacote todas as dependências em um diretório vendor/,
>> que você pode fazer um tar e subir para aquele servidor de produção que não
>> sai pra internet, e então instalar normalmente, de forma que mesmo pacotes
>> com XS funcionem. O carton se empacotes junto, inclusive, para o caso da
>> máquina destino não ter carton instalado.
>>
>> Assim eu tenho o controle exato de cada versão de cada pacote.
>>
>> O CPAN é fantástico, sempre foi, mas eu diria que dá pra dividi-lo em
>> duas eras: antes e depois do Carton.
>>
>>
>>
>> * Curiosamente hoje, a instalação do Perlbrew falhou num debian 6 que eu
>> to configurando e eu precisei instalar o pacote Devel::PatchPerl
>> diretamente no sistema com o cpan tradicional (root).
>>
>> ** O drawback é que eu preciso de acesso ao compilador.
>>
>> *** Sim, raramente acontece, mas eu já precisei achar uma combinação X de
>> versões pra funcionar redondo, mas nada além de editar o cpanfile e rodar
>> carton install denovo.
>>
>> []'s
>>
>>
>> 2014-04-04 15:24 GMT-03:00 Samir Cury :
>>
>>> E ai pessoal,
>>>
>>> Acabei de passar por um pequeno problema com o CPAN e achei uma solucao
>>> interessante. Tambem gostaria de perguntar ao pessoal que e mais fa do
>>> CPAN, o que acham de modulos que sao distribuidos como pacotes. Se e
>>> bom/ruim para o ecossistema.
>>>
>>> Entao, o problema foi quando tentei cpan install CouchDB::Client. Que
>>> funcionou em outras maquinas mas nao no Fedora 19 que tenho aqui. Quebrou
>>> em algum modulo referente a testes, que dependia do Module::Build que
>>> tambem falhou.
>>>
>>> Nao querendo gastar muito tempo com isso, fui para o plano B : Pacotes
>>> de modulos. O motivo dos pacotes serem meu plano B e que cada distribuicao
>>> gosta de um nome diferente e as vezes e irritante ter que adivinhar, mas
>>> acabei de achar um macete :
>>>
>>> yum install 'perl(Module::Build)'
>>>
>>> O pessoal do YUM mandou muito bem. Uma vez que o Module::Build foi
>>> instalado, procurei pelo pacote do modulo CouchDB::Client. Nao existia.
>>> Porem voltando para o CPAN e tentando de novo o CouchDB::Client foi
>>> tranquilo. Posso voltar a trabalhar no que eu preciso trabalha

Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes

[Renato Santos]

Não sei quanto ao Fedora em especifico, mas geralmente, se você não esta
instalando os pacotes usando local::lib ou perlbrew, você pode, sem querer,
acabar instalando módulos novos em cima dos módulos do sistema, o que
poderia, teoricamente, quebrar o sistema,

é um pouco mais grave quando o sistema alterou o fonte de alguns módulos do
perl-core, pois ai quando você atualiza, você remove essa alteração e ai
começa as loucuras.

Você pode dar uma olhada no https://metacpan.org/pod/local::lib
pois ele cria um ambiente, que quando você rodar o programa cpan, ele vai
instalar na pasta ~/perl5 evitando conflitos com o sistema.

Com ele, você continua usando o mesmo binário do perl do sistema, porém,
com as libs apontando para carregar antes em ~/perl5.


Já com perlbrew (http://sao-paulo.pm.org/equinocio/2011/set/3) você compila
uma versão do perl para um determinado usuário (ou vários) totalmente
independente do perl do SO.

Ai você pode instalar os módulos em cada versão do perl separadamente.

Todos os módulos feitos puramente em perl, teoricamente, funcionam em
"todas" plataformas que o perl é possivelmente compilado.

Porém, uma boa parte dos módulos fazem uso de XS e link externo com outras
libs.

Esse não parece ser o caso do CouchDB::Client, pois olhando o código por
cima, ele se comunica com o CouchDB via HTTP.

Mas é o caso do SDL, por exemplo, ou DBD::Pg (que precisa saber onde ta a
lib do postgres)

Ai criaram os pacotes que começam com Alien:: que prepara o ambiente,
compila e linka os modulos, ex: Alien::SDL



2014-04-04 15:24 GMT-03:00 Samir Cury :

> E ai pessoal,
>
> Acabei de passar por um pequeno problema com o CPAN e achei uma solucao
> interessante. Tambem gostaria de perguntar ao pessoal que e mais fa do
> CPAN, o que acham de modulos que sao distribuidos como pacotes. Se e
> bom/ruim para o ecossistema.
>
> Entao, o problema foi quando tentei cpan install CouchDB::Client. Que
> funcionou em outras maquinas mas nao no Fedora 19 que tenho aqui. Quebrou
> em algum modulo referente a testes, que dependia do Module::Build que
> tambem falhou.
>
> Nao querendo gastar muito tempo com isso, fui para o plano B : Pacotes de
> modulos. O motivo dos pacotes serem meu plano B e que cada distribuicao
> gosta de um nome diferente e as vezes e irritante ter que adivinhar, mas
> acabei de achar um macete :
>
> yum install 'perl(Module::Build)'
>
> O pessoal do YUM mandou muito bem. Uma vez que o Module::Build foi
> instalado, procurei pelo pacote do modulo CouchDB::Client. Nao existia.
> Porem voltando para o CPAN e tentando de novo o CouchDB::Client foi
> tranquilo. Posso voltar a trabalhar no que eu preciso trabalhar, nao em
> consertar testes :-).
>
> Mas acho interessante a discussao sobre CPAN x Pacotes. Uma das principais
> desvantagens que ouvi uma vez (nao conferi) e que o CPAN acaba "nao
> sabendo" o que o Yum/Apt instalou. Procede? Existe algum efeito colateral
> grave conhecido?
>
> 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] CPAN x Pacotes Ou CPAN + Pacotes

[Samir Cury]

Interessante.

Agora, se olharmos de um ponto de vista "mais sysadmin" -- voce *quer* que
os modulos estejam disponiveis system-wide (todos usuarios/ambientes) e nao
se importa tanto com as versoes especificas dos modulos -- porque a
principio a maioria das aplicacoes serao compativeis com uma faixa grande
de versoes de cada modulo.

(acredito que da menos trabalho pensar assim e consertar individualmente o
que quebrar, do que fazer um bootstrap pra cada aplicacao pra ter certeza
que "funcionou, nao respira")

Seria o CPAN puro como root ainda sim a melhor opcao neste caso?

Valeu pela dica dos modulos dos pacotes sobre-escritos. Realmente e para se
considerar. No entanto, nao vejo tanto mal de ter o mesmo modulo presente,
outra versao. Concordo que e tosco ter "rpm -qa | grep Modulo" dizendo uma
coisa e quando voce carrega o modulo ser outra.

Quando o RPM for desisntalado deve remover o arquivo, dai o CPAN
provavelmente vai se perder. Mas enquanto nao remover nada deve ser
~tranquilo.

O que estou tentando entender e - qual a melhor maneira de configurar um
sistema padrao com ferramentas padrao (cpan, rpm, apt). Pelo visto o preco
de eventuais gambiarras como a que descrevi nao causaria mais problemas do
que o tempo gasto debugando o teste que nao passou no CPAN. Indesejavel,
mas nao fatal.

Pelo que entendi no melhor dos mundos -- da instalacao padrao, voce escolhe
entre 2 caminhos :

  * usa CPAN como root - se um teste quebrar, vai perder um tempo
  * usa RPMs para tudo - se nao existir um pacote para o modulo, vai ter
que comecar a "sujar" o sistema com modulos instalados pelo CPAN

E tenta nao misturar.

Abs


2014-04-04 11:48 GMT-07:00 Blabos de Blebe :

> Olá,
>
> Normalmente eu evito mexer no Perl do sistema. O fedora, inclusive, é
> historicamente bastante hostil ao lidar com o Perl, diga-se de passagem.
>
> Nos meus projetos, eu procedo da seguinte forma:
>
> 1) Instalar perlbrew*
> 2) Instalar a versão do Perl que eu vou usar**
> 3) Instalar o cpanm (App::cpanminus)
> 4) se máquina de desenvolvimento então
> instalar Carton e Dist::Zilla
> end-se
>
> Daí, para os meus módulos ou aplicações, faço o gerenciamento de pacotes
> com Carton, que me deixa travar a versão exata*** de cada módulo.
>
> Para os módulos não é necessário, mas para as aplicações, o carton permite
> que você empacote todas as dependências em um diretório vendor/, que você
> pode fazer um tar e subir para aquele servidor de produção que não sai pra
> internet, e então instalar normalmente, de forma que mesmo pacotes com XS
> funcionem. O carton se empacotes junto, inclusive, para o caso da máquina
> destino não ter carton instalado.
>
> Assim eu tenho o controle exato de cada versão de cada pacote.
>
> O CPAN é fantástico, sempre foi, mas eu diria que dá pra dividi-lo em duas
> eras: antes e depois do Carton.
>
>
>
> * Curiosamente hoje, a instalação do Perlbrew falhou num debian 6 que eu
> to configurando e eu precisei instalar o pacote Devel::PatchPerl
> diretamente no sistema com o cpan tradicional (root).
>
> ** O drawback é que eu preciso de acesso ao compilador.
>
> *** Sim, raramente acontece, mas eu já precisei achar uma combinação X de
> versões pra funcionar redondo, mas nada além de editar o cpanfile e rodar
> carton install denovo.
>
> []'s
>
>
> 2014-04-04 15:24 GMT-03:00 Samir Cury :
>
>> E ai pessoal,
>>
>> Acabei de passar por um pequeno problema com o CPAN e achei uma solucao
>> interessante. Tambem gostaria de perguntar ao pessoal que e mais fa do
>> CPAN, o que acham de modulos que sao distribuidos como pacotes. Se e
>> bom/ruim para o ecossistema.
>>
>> Entao, o problema foi quando tentei cpan install CouchDB::Client. Que
>> funcionou em outras maquinas mas nao no Fedora 19 que tenho aqui. Quebrou
>> em algum modulo referente a testes, que dependia do Module::Build que
>> tambem falhou.
>>
>> Nao querendo gastar muito tempo com isso, fui para o plano B : Pacotes de
>> modulos. O motivo dos pacotes serem meu plano B e que cada distribuicao
>> gosta de um nome diferente e as vezes e irritante ter que adivinhar, mas
>> acabei de achar um macete :
>>
>> yum install 'perl(Module::Build)'
>>
>> O pessoal do YUM mandou muito bem. Uma vez que o Module::Build foi
>> instalado, procurei pelo pacote do modulo CouchDB::Client. Nao existia.
>> Porem voltando para o CPAN e tentando de novo o CouchDB::Client foi
>> tranquilo. Posso voltar a trabalhar no que eu preciso trabalhar, nao em
>> consertar testes :-).
>>
>> Mas acho interessante a discussao sobre CPAN x Pacotes. Uma das
>> principais desvantagens que ouvi uma vez (nao conferi) e que o CPAN acaba
>> "nao sabendo" o que o Yum/Apt instalou. Procede? Existe algum efeito
>> colateral grave conhecido?
>>
>> Abracos,
>> Samir
>>
>> ___
>> Rio-pm mailing list
>> Rio-pm@pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>
>
> ___
> Rio-pm mailing list
> Rio-pm@pm.org

Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes

[Blabos de Blebe]

Olá,

Normalmente eu evito mexer no Perl do sistema. O fedora, inclusive, é
historicamente bastante hostil ao lidar com o Perl, diga-se de passagem.

Nos meus projetos, eu procedo da seguinte forma:

1) Instalar perlbrew*
2) Instalar a versão do Perl que eu vou usar**
3) Instalar o cpanm (App::cpanminus)
4) se máquina de desenvolvimento então
instalar Carton e Dist::Zilla
end-se

Daí, para os meus módulos ou aplicações, faço o gerenciamento de pacotes
com Carton, que me deixa travar a versão exata*** de cada módulo.

Para os módulos não é necessário, mas para as aplicações, o carton permite
que você empacote todas as dependências em um diretório vendor/, que você
pode fazer um tar e subir para aquele servidor de produção que não sai pra
internet, e então instalar normalmente, de forma que mesmo pacotes com XS
funcionem. O carton se empacotes junto, inclusive, para o caso da máquina
destino não ter carton instalado.

Assim eu tenho o controle exato de cada versão de cada pacote.

O CPAN é fantástico, sempre foi, mas eu diria que dá pra dividi-lo em duas
eras: antes e depois do Carton.



* Curiosamente hoje, a instalação do Perlbrew falhou num debian 6 que eu to
configurando e eu precisei instalar o pacote Devel::PatchPerl diretamente
no sistema com o cpan tradicional (root).

** O drawback é que eu preciso de acesso ao compilador.

*** Sim, raramente acontece, mas eu já precisei achar uma combinação X de
versões pra funcionar redondo, mas nada além de editar o cpanfile e rodar
carton install denovo.

[]'s


2014-04-04 15:24 GMT-03:00 Samir Cury :

> E ai pessoal,
>
> Acabei de passar por um pequeno problema com o CPAN e achei uma solucao
> interessante. Tambem gostaria de perguntar ao pessoal que e mais fa do
> CPAN, o que acham de modulos que sao distribuidos como pacotes. Se e
> bom/ruim para o ecossistema.
>
> Entao, o problema foi quando tentei cpan install CouchDB::Client. Que
> funcionou em outras maquinas mas nao no Fedora 19 que tenho aqui. Quebrou
> em algum modulo referente a testes, que dependia do Module::Build que
> tambem falhou.
>
> Nao querendo gastar muito tempo com isso, fui para o plano B : Pacotes de
> modulos. O motivo dos pacotes serem meu plano B e que cada distribuicao
> gosta de um nome diferente e as vezes e irritante ter que adivinhar, mas
> acabei de achar um macete :
>
> yum install 'perl(Module::Build)'
>
> O pessoal do YUM mandou muito bem. Uma vez que o Module::Build foi
> instalado, procurei pelo pacote do modulo CouchDB::Client. Nao existia.
> Porem voltando para o CPAN e tentando de novo o CouchDB::Client foi
> tranquilo. Posso voltar a trabalhar no que eu preciso trabalhar, nao em
> consertar testes :-).
>
> Mas acho interessante a discussao sobre CPAN x Pacotes. Uma das principais
> desvantagens que ouvi uma vez (nao conferi) e que o CPAN acaba "nao
> sabendo" o que o Yum/Apt instalou. Procede? Existe algum efeito colateral
> grave conhecido?
>
> Abracos,
> Samir
>
> ___
> 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] CPAN x Pacotes Ou CPAN + Pacotes

[Bruno Buss]

Se você estiver usando CPAN as in instalando os pacotes como root no
sistema... isso e' de fato muito ruim, pois o código baixado pelo CPAN pode
sobrescrever os arquivos do pacote do seu sistema ou vice versa.

Se voce estiver usando local::lib ou perlbrew, e instalando via cpan nesses
locais e usando as libs do sistema somente como fallback... não vejo
problema em instalar coisas pelo sistema de pacotes da sua distro, ainda
mais para coisas mais chatas que dependem de libs externas (que precisam
ser compiladas e etc).

[ ]'s
Buss


2014-04-04 15:24 GMT-03:00 Samir Cury :

> E ai pessoal,
>
> Acabei de passar por um pequeno problema com o CPAN e achei uma solucao
> interessante. Tambem gostaria de perguntar ao pessoal que e mais fa do
> CPAN, o que acham de modulos que sao distribuidos como pacotes. Se e
> bom/ruim para o ecossistema.
>
> Entao, o problema foi quando tentei cpan install CouchDB::Client. Que
> funcionou em outras maquinas mas nao no Fedora 19 que tenho aqui. Quebrou
> em algum modulo referente a testes, que dependia do Module::Build que
> tambem falhou.
>
> Nao querendo gastar muito tempo com isso, fui para o plano B : Pacotes de
> modulos. O motivo dos pacotes serem meu plano B e que cada distribuicao
> gosta de um nome diferente e as vezes e irritante ter que adivinhar, mas
> acabei de achar um macete :
>
> yum install 'perl(Module::Build)'
>
> O pessoal do YUM mandou muito bem. Uma vez que o Module::Build foi
> instalado, procurei pelo pacote do modulo CouchDB::Client. Nao existia.
> Porem voltando para o CPAN e tentando de novo o CouchDB::Client foi
> tranquilo. Posso voltar a trabalhar no que eu preciso trabalhar, nao em
> consertar testes :-).
>
> Mas acho interessante a discussao sobre CPAN x Pacotes. Uma das principais
> desvantagens que ouvi uma vez (nao conferi) e que o CPAN acaba "nao
> sabendo" o que o Yum/Apt instalou. Procede? Existe algum efeito colateral
> grave conhecido?
>
> Abracos,
> Samir
>
> ___
> Rio-pm mailing list
> Rio-pm@pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>



-- 
Bruno C. Buss
http://www.brunobuss.net
___
Rio-pm mailing list
Rio-pm@pm.org
http://mail.pm.org/mailman/listinfo/rio-pm

[Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes

[Samir Cury]

E ai pessoal,

Acabei de passar por um pequeno problema com o CPAN e achei uma solucao
interessante. Tambem gostaria de perguntar ao pessoal que e mais fa do
CPAN, o que acham de modulos que sao distribuidos como pacotes. Se e
bom/ruim para o ecossistema.

Entao, o problema foi quando tentei cpan install CouchDB::Client. Que
funcionou em outras maquinas mas nao no Fedora 19 que tenho aqui. Quebrou
em algum modulo referente a testes, que dependia do Module::Build que
tambem falhou.

Nao querendo gastar muito tempo com isso, fui para o plano B : Pacotes de
modulos. O motivo dos pacotes serem meu plano B e que cada distribuicao
gosta de um nome diferente e as vezes e irritante ter que adivinhar, mas
acabei de achar um macete :

yum install 'perl(Module::Build)'

O pessoal do YUM mandou muito bem. Uma vez que o Module::Build foi
instalado, procurei pelo pacote do modulo CouchDB::Client. Nao existia.
Porem voltando para o CPAN e tentando de novo o CouchDB::Client foi
tranquilo. Posso voltar a trabalhar no que eu preciso trabalhar, nao em
consertar testes :-).

Mas acho interessante a discussao sobre CPAN x Pacotes. Uma das principais
desvantagens que ouvi uma vez (nao conferi) e que o CPAN acaba "nao
sabendo" o que o Yum/Apt instalou. Procede? Existe algum efeito colateral
grave conhecido?

Abracos,
Samir
___
Rio-pm mailing list
Rio-pm@pm.org
http://mail.pm.org/mailman/listinfo/rio-pm