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 <samircu...@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 <bla...@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 <samircu...@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@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 >> > > > _______________________________________________ > 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
