[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