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 <[email protected]>: > 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 <[email protected]>: > >> 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 >> > > > > -- > Bruno C. Buss > http://www.brunobuss.net > > _______________________________________________ > Rio-pm mailing list > [email protected] > http://mail.pm.org/mailman/listinfo/rio-pm > -- Saravá, Renato CRON http://www.renatocron.com/blog/ @renato_cron <http://twitter.com/#!/renato_cron>
_______________________________________________ Rio-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/rio-pm
