[Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes
Aureliano Guedes
guedes_1000 em hotmail.com
Sexta Abril 4 12:51:28 PDT 2014
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
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20140404/53934d5c/attachment-0001.html>
Mais detalhes sobre a lista de discussão Rio-pm