[Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes
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
Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes
Se você estiver usando CPAN as in instalando os pacotes como root no sistema... isso e' de fato muito ruim, pois o código baixado pelo CPAN pode sobrescrever os arquivos do pacote do seu sistema ou vice versa. Se voce estiver usando local::lib ou perlbrew, e instalando via cpan nesses locais e usando as libs do sistema somente como fallback... não vejo problema em instalar coisas pelo sistema de pacotes da sua distro, ainda mais para coisas mais chatas que dependem de libs externas (que precisam ser compiladas e etc). [ ]'s Buss 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 -- Bruno C. Buss http://www.brunobuss.net ___ Rio-pm mailing list Rio-pm@pm.org http://mail.pm.org/mailman/listinfo/rio-pm
Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes
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
Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes
Não sei quanto ao Fedora em especifico, mas geralmente, se você não esta instalando os pacotes usando local::lib ou perlbrew, você pode, sem querer, acabar instalando módulos novos em cima dos módulos do sistema, o que poderia, teoricamente, quebrar o sistema, é um pouco mais grave quando o sistema alterou o fonte de alguns módulos do perl-core, pois ai quando você atualiza, você remove essa alteração e ai começa as loucuras. Você pode dar uma olhada no https://metacpan.org/pod/local::lib pois ele cria um ambiente, que quando você rodar o programa cpan, ele vai instalar na pasta ~/perl5 evitando conflitos com o sistema. Com ele, você continua usando o mesmo binário do perl do sistema, porém, com as libs apontando para carregar antes em ~/perl5. Já com perlbrew (http://sao-paulo.pm.org/equinocio/2011/set/3) você compila uma versão do perl para um determinado usuário (ou vários) totalmente independente do perl do SO. Ai você pode instalar os módulos em cada versão do perl separadamente. Todos os módulos feitos puramente em perl, teoricamente, funcionam em todas plataformas que o perl é possivelmente compilado. Porém, uma boa parte dos módulos fazem uso de XS e link externo com outras libs. Esse não parece ser o caso do CouchDB::Client, pois olhando o código por cima, ele se comunica com o CouchDB via HTTP. Mas é o caso do SDL, por exemplo, ou DBD::Pg (que precisa saber onde ta a lib do postgres) Ai criaram os pacotes que começam com Alien:: que prepara o ambiente, compila e linka os modulos, ex: Alien::SDL 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 -- Saravá, Renato CRON http://www.renatocron.com/blog/ @renato_cron http://twitter.com/#!/renato_cron ___ Rio-pm mailing list Rio-pm@pm.org http://mail.pm.org/mailman/listinfo/rio-pm
Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes
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)
Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes
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.b...@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 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
Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes
Nunca aconselhei atualizar o Perl do sistema, e para garantir minha integridade, continuo não aconselhando, mas... 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).Não sei quanto a módulos usados pelo sistema, posso fazer esse teste depois. Mas não deu problema nenhum. From: bruno.b...@gmail.com Date: Fri, 4 Apr 2014 16:35:39 -0300 To: rio-pm@pm.org Subject: Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes 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::Zillaend-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
Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes
desci um Debian nele, Isso. Não Fedora* :) depois atualizei o Perl (do sistema), e 'PA' nada aconteceu Parabéns :) === Vejam, não sou sysadmin, então tomem algumas coisas como licença poética: 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? 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. === * 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. 2014-04-04 16:51 GMT-03:00 Aureliano Guedes guedes_1...@hotmail.com: Nunca aconselhei atualizar o Perl do sistema, e para garantir minha integridade, continuo não aconselhando, mas... 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). Não sei quanto a módulos usados pelo sistema, posso fazer esse teste depois. Mas não deu problema nenhum. -- From: bruno.b...@gmail.com Date: Fri, 4 Apr 2014 16:35:39 -0300 To: rio-pm@pm.org Subject: Re: [Rio-pm] CPAN x Pacotes Ou CPAN + Pacotes 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
