<div dir="ltr">> <span style="font-family:arial,sans-serif;font-size:13px">desci um Debian nele,</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Isso. Não Fedora* :)</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">> depois atualizei o Perl (do sistema), e 'PA' nada aconteceu</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Parabéns :)</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><font face="arial, sans-serif">===</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Vejam, não sou sysadmin, então tomem algumas coisas como licença poética:</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">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?</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">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.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">===</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">* 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.</font></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2014-04-04 16:51 GMT-03:00 Aureliano Guedes <span dir="ltr"><<a href="mailto:guedes_1000@hotmail.com" target="_blank">guedes_1000@hotmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr">Nunca aconselhei atualizar o Perl do sistema, e para garantir minha integridade, continuo não aconselhando, mas...<div><br></div><div>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).</div>
<div>Não sei quanto a módulos usados pelo sistema, posso fazer esse teste depois. Mas não deu problema nenhum.</div><div><span style="font-size:12pt"> </span></div><div><br><div><hr>From: <a href="mailto:bruno.buss@gmail.com" target="_blank">bruno.buss@gmail.com</a><br>
Date: Fri, 4 Apr 2014 16:35:39 -0300<br>To: <a href="mailto:rio-pm@pm.org" target="_blank">rio-pm@pm.org</a><br>Subject: Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes<div><div class="h5"><br><br><div dir="ltr">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 :-)<br>
<div>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? ;)</div><div><br>[ ]'s</div><div>
Buss<br><br><div>2014-04-04 16:14 GMT-03:00 Samir Cury <span dir="ltr"><<a href="mailto:samircurys@gmail.com" target="_blank">samircurys@gmail.com</a>></span>:<br><blockquote style="border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Interessante.<div><br></div><div>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. </div>
<div><br></div><div>(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")</div><div><br>
</div><div>Seria o CPAN puro como root ainda sim a melhor opcao neste caso?</div><div><br></div><div>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. </div>
<div><br></div><div>Quando o RPM for desisntalado deve remover o arquivo, dai o CPAN provavelmente vai se perder. Mas enquanto nao remover nada deve ser ~tranquilo.</div><div><br></div><div>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.</div>
<div><br></div><div>Pelo que entendi no melhor dos mundos -- da instalacao padrao, voce escolhe entre 2 caminhos :</div><div><br></div><div> * usa CPAN como root - se um teste quebrar, vai perder um tempo</div><div> * 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</div>
<div><br></div><div>E tenta nao misturar.</div><div><br></div><div>Abs</div></div><div><br><br><div>2014-04-04 11:48 GMT-07:00 Blabos de Blebe <span dir="ltr"><<a href="mailto:blabos@gmail.com" target="_blank">blabos@gmail.com</a>></span>:<div>
<div><br>
<blockquote style="border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Olá,<br></div><div><br></div><div>Normalmente eu evito mexer no Perl do sistema. O fedora, inclusive, é historicamente bastante hostil ao lidar com o Perl, diga-se de passagem.</div>
<div><br></div><div>
Nos meus projetos, eu procedo da seguinte forma:</div><div><br></div><div>1) Instalar perlbrew*</div><div>2) Instalar a versão do Perl que eu vou usar**</div><div>3) Instalar o cpanm (App::cpanminus)</div><div>4) se máquina de desenvolvimento então</div>
<div> instalar Carton e Dist::Zilla</div><div> end-se</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Assim eu tenho o controle exato de cada versão de cada pacote.</div><div><br></div><div>O CPAN é fantástico, sempre foi, mas eu diria que dá pra dividi-lo em duas eras: antes e depois do Carton.</div>
<div>
<br></div><div><br></div><div><br></div><div>* 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).</div>
<div><br></div><div>** O drawback é que eu preciso de acesso ao compilador.</div><div><br></div><div>*** 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.</div>
<div><br></div><div>[]'s</div><div><br><br><div><div>2014-04-04 15:24 GMT-03:00 Samir Cury <span dir="ltr"><<a href="mailto:samircurys@gmail.com" target="_blank">samircurys@gmail.com</a>></span>:<br>
</div><blockquote style="border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">E ai pessoal,<div><div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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 :<br>
<div><br></div><div>yum install 'perl(Module::Build)'<br></div></div><div><br></div><div>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 :-).</div>
<div><br></div><div>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?</div>
<div><br></div><div>Abracos,<br>Samir</div></div></div></div>
<br><div>_______________________________________________<br>
Rio-pm mailing list<br>
<a href="mailto:Rio-pm@pm.org" target="_blank">Rio-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br></div></blockquote></div><br></div></div>
<br>_______________________________________________<br>
Rio-pm mailing list<br>
<a href="mailto:Rio-pm@pm.org" target="_blank">Rio-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br></blockquote></div></div></div><br></div>
<br>_______________________________________________<br>
Rio-pm mailing list<br>
<a href="mailto:Rio-pm@pm.org" target="_blank">Rio-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Bruno C. Buss<br><a href="http://www.brunobuss.net" target="_blank">http://www.brunobuss.net</a>
</div></div>
<br>_______________________________________________
Rio-pm mailing list
<a href="mailto:Rio-pm@pm.org" target="_blank">Rio-pm@pm.org</a>
<a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a></div></div></div></div> </div></div>
<br>_______________________________________________<br>
Rio-pm mailing list<br>
<a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br></blockquote></div><br></div>