[Cascavel-pm] Problemas ao instalar Modulo

Gilmar Santos Jr jgasjr em gmail.com
Sábado Junho 12 07:18:56 PDT 2010


Em 12 de junho de 2010 09:39, Eden Cardim <edencardim em gmail.com> escreveu:
> 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é?)

A solução é fazer o que for *preciso* fazer. Muitas correções de bugs
ou features novas são irrelevantes.

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

E depois de algumas "soluções" dessa vc reinstala o S.O. Decisão de cada um ;)

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

Se você tem recursos de hardware para que cada sistema rode no seu
próprio ambiente, é melhor mesmo (se é pra cada um ser auto-contido,
pq não partir logo pra virtualização e rodar cada sistema no seu
próprio servidor? Muita gente por aí adota essa abordagem com
sucesso).

Quanto à relevância de remover dependências desnecessárias, vc pode
considerar assim até o dia em que esse lixo te causar uma dor de
cabeça enorme por vc já ter "esquecido" que ele está lá.

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

Se estivermos falando de plataformas em termo de "hardware", o
processo é o mesmo para 1 ou N plataformas. Se estivermos falando de
"Sistema Operacional", aí realmente cada sistema tem sua solução mais
adequada.

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

Pois justamente em sistemas corporativos é que faz mais sentido.
Ambientes que preciso fazer um plano de mudança antes de fazer
qualquer coisa, com as opções de retorno muito bem definidas. Sem o
uso de pacotes, tenho que partir para imagens. Retornar a versão de um
pacote é muito mais rápido do que restaurar a imagem de um servidor.

> (...) 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.

Se sua equipe de desenvolvimento é mais rápida que os empacotadores e
tem tempo para ficar verificando a versão mais recentes de todos os
módulos usados todos os dias, que bom. Não vejo muitas equipes assim
por aí...

E quanto à defasagem, sorteie N módulos CPAN (ou escolha um conjunto
de sua preferência) e verifique a versão mais recente do CPAN e do
debian unstable.

Por fim, boa parte do que estamos debatendo faz parte da política de
cada empresa/organização. O uso de pacotes é bem adequado às políticas
que tive contato até agora, o que não quer dizer que seja solução
universal. Acho importante conhecer as alternativas e as vantagens e
desvantagens de cada uma, assim a análise de cada caso fica mais
precisa.

[ ]'s
Gilmar


Mais detalhes sobre a lista de discussão Cascavel-pm