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 <[email protected]>: > 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 <[email protected]>: > >> 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 >> [email protected] >> http://mail.pm.org/mailman/listinfo/rio-pm >> > > > _______________________________________________ > Rio-pm mailing list > [email protected] > http://mail.pm.org/mailman/listinfo/rio-pm >
_______________________________________________ Rio-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/rio-pm
