[Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes

Sexta Abril 4 12:45:06 PDT 2014

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 <bruno.buss em gmail.com>:

> 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
>

-- 
Saravá,
Renato CRON
http://www.renatocron.com/blog/
@renato_cron <http://twitter.com/#!/renato_cron>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20140404/056155d5/attachment.html>