[Cascavel-pm] Problemas ao instalar Modulo

[Eden Cardim]

>>>>> "Gilmar" == Gilmar Santos <jgasjr em gmail.com> writes:

    Gilmar> Do mesmo modo que usar a versão mais recente de um módulo
    Gilmar> (ou qualquer software) é assumir o risco de usar software
    Gilmar> não muito testado.

Então a solução é ficar preso com a biblioteca bugada por 2 anos? Esse
risco do qual você está falando só existe se você não tiver uma boa
política de homologação. (Você tem uma política de homologação, né?)
    
    Gilmar> Em 7 anos usando debian e 6 programando em Perl acho que só
    Gilmar> precisei instalar um módulo via cpan nos casos que não tinha
    Gilmar> pacote (e em boa parte desses casos fiz backport dos pacotes
    Gilmar> da unstable, quando precisei em servidores).

Pois é, em 11 anos programando perl e 5 anos como desenvolvedor e
consultor de alguns dos módulos mais usados do CPAN, 99% dos problemas
dos usuários são resolvidos com um "cpan upgrade".
    
    Gilmar> E ainda supondo a possibilidade de usar módulos sem features
    Gilmar> ou com alguns bugs, mas poder gerenciar isso através do
    Gilmar> sistema de pacotes, eu prefiro do que instalar via cpan e
    Gilmar> não ter atualizações automáticas, resolução de dependências
    Gilmar> e poder remover depois as dependências desnecessárias
    Gilmar> (quando sai uma nova versão do módulo que depende da libfoo2
    Gilmar> ao invés da libfoo1, nesse caso a libfoo1 vai pro saco, ao
    Gilmar> invés de ficar como lixo no sistema).

Acho que estamos falando de coisas diferentes aqui, mas vamos lá. Uma
coisa é implantar uma biblioteca para utilizar durante o
desenvolvimento, outra é implantar o sistema de produção per se. Em
ambos os casos, a "remoção de dependências desnecessárias" é
irrelevante. Se a biblioteca for para desenvolvimento, você vai precisar
das versões antigas para testar/resolver problemas de
retro-compatibilidade. Se for para release/implantação, o correto é
distribuir versões auto-contidas do software, invés de implantar
bibliotecas para uso global no sistema.
    
    Gilmar> No caso extremo, em que eu preciso da feature na versão nova
    Gilmar> ou um bug corrigido me afeta, eu baixo o fonte do pacote
    Gilmar> junto com o fonte da versão nova e faço um pacote. Dá mais
    Gilmar> trabalho do que via cpan, mas posso usar o pacote em várias
    Gilmar> máquinas e ter todas as vantagens/facilidades que citei
    Gilmar> antes.

OK, isso funciona, até a hora em que o teu ambiente de implantação
envolver 4 ou mais plataformas diferentes. Pelo menos no meu mundo,
"casos extremos" envolvem mais plataformas do que isso.
    
    Gilmar> No dia-a-dia uso debian testing com alguns pacotes da
    Gilmar> unstable e vejo muito pouca defasagem entre as versões
    Gilmar> empacotadas dos módulos e o upstream. No cenário de uso do
    Gilmar> debian stable o problema aparece mais, pois são 2 anos e
    Gilmar> meio entra as versões. Mas ainda assim isso só seria
    Gilmar> impactante se algum sistema *realmente* precisasse da versão
    Gilmar> mais recente e que tal sistema *realmente* seja
    Gilmar> necessário. Já me deparei com casos em que não eram (achamos
    Gilmar> outro software similar ou ficamos com uma versão do sistema
    Gilmar> que funcionava com as libs que tínhamos).

Ah, como eu suspeitava... O uso do termo "dia-a-dia" é um indicador de
que você está falando sobre uso doméstico, e nesse caso talvez faça
sentido usar pacotes sim. Mas em sistemas de grande porte e de missão
crítica, as atualizações dos módulos são *muito* importantes,
principalmente porque o ciclo de desenvolvimento dos módulos é
propulsiondo pelos casos de uso que surgem no contexto desses sistemas
de produção. Enfim, é frustrante, como desenvolvedor de módulos, ver
usuários reclamando de problemas com módulos, quando o problema é com as
práticas de engenharia de software que eles adotam. Já passei por
inúmeros casos onde alguém falou "catalyst é uma porcaria, não faz X
direito", quando fui ver, era uma versão defasada instalada por pacote e
o bug tinha sido corrigido duas semanas depois num release subsequente
mas os empacotadores não acompanharam. A culpa nem é dos empacotadores,
não tem como uma equipe de empacotadores acompanharem e adotarem as
políticas de release de todos os projetos no repositório de uma
distribuição e também não tem como os desenvolvedores de um projeto
fazerem o mesmo para todas as distros existentes. Mas, disseminar esse
tipo de prática não contribui nem um pouco com a popularidade da
linguagem.