[Cascavel-pm] Problemas ao instalar Modulo
Thiago Glauco Sanchez
thiagoglauco em ticursos.net
Sábado Junho 12 05:56:49 PDT 2010
Eden told:
>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.
Existem empresas que para atualizar um pacth, um firmware ou uma lib o
processo de homologação é de mais
de um mês... tempo mais que suficiente para grandes problemas acontecerem.
Em 12/06/2010 09:39, Eden Cardim escreveu:
>>>>>> "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.
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>
>
--
Thiago Glauco Sanchez
Intrutor Perl e Redes
www.ticursos.net
Mais detalhes sobre a lista de discussão Cascavel-pm