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

Blabos de Blebe blabos em gmail.com
Sexta Abril 4 13:16:12 PDT 2014


> 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 <guedes_1000 em hotmail.com>:

> 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.buss em gmail.com
> Date: Fri, 4 Apr 2014 16:35:39 -0300
> To: rio-pm em 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 <samircurys em gmail.com>:
>
> 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 <blabos em gmail.com>:
>
> 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 <samircurys em gmail.com>:
>
> 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 em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
>
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
>
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
>
>
>
> --
> Bruno C. Buss
> http://www.brunobuss.net
>
> _______________________________________________ Rio-pm mailing list
> Rio-pm em pm.org http://mail.pm.org/mailman/listinfo/rio-pm
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20140404/edea21be/attachment.html>


Mais detalhes sobre a lista de discussão Rio-pm