[Cascavel-pm] Problemas ao instalar Modulo

[Eden Cardim]

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

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

Irrelevantes? Deve ser por conta dessa mentalidade que os contratos no
Brasil são tão baratos. Quando o teu sistema sustentar um negócio que
movimenta alguns milhões de dólares, você não vai poder se dar o luxo de
ignorar bugs ou features.

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

"reinstala o S.O." porque? Estamos num fórum de "técnicos de uindous"? A
"solução" se trata de consertar e reimplantar o software, inserindo o
mínimo de efeitos colaterais, que é a única forma de se resolver um
bug. Se uma atualização de software degenera a sua plataforma, tem algo
muito errado na abordagem.

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

É piada isso? Boa parte dos sistemas sérios não podem ser virtualizados,
a linguagem já é lenta em hardware "de verdade" e outras soluções são
lentas por natureza, precisam de todos os recursos que puderem ter.
    
    Gilmar> Quanto à relevância de remover dependências desnecessárias,
    Gilmar> vc pode considerar assim até o dia em que esse lixo te
    Gilmar> causar uma dor de cabeça enorme por vc já ter "esquecido"
    Gilmar> que ele está lá.

"lixo"? Você não leu o que eu falei sobre retro-compatibilidade? E como
assim "esquecido"? Um sistema de produção que valha o nome tem tudo
documentado, monitorado e catalogado. Ou você está falando do laptop que
você usa em casa?
 
    Gilmar> Se estivermos falando de plataformas em termo de "hardware",
    Gilmar> o processo é o mesmo para 1 ou N plataformas. Se estivermos
    Gilmar> falando de "Sistema Operacional", aí realmente cada sistema
    Gilmar> tem sua solução mais adequada.

"plataforma" é a combinação do hardware e do software básico que estiver
dando suporte à execução do software de negócio. Então qualquer mudança,
no hardware ou no software básico requer um procedimento de implantação
específico.

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

É muito mais rápido e é muito mais porco também (vide
retrocompatibilidade, implantação, etc. que eu mencionei antes). E err,
não precisa de uma "imagem" do sistema operacional, uma vez estabelecida
a plataforma, você pode implantar e remover sistemas a vontade, é
exatamente pra isso que serve uma plataforma. Me parece que você está
viciado nos pacotes porque acha que essa é a única forma de se compilar
bibliotecas para serem usadas em sistemas de software. Existem inúmeras
distribuições de software que adotam uma estratégia auto-contida, isto
significa que todo o software do sistema de negócios fica agrupado num
único lugar, tipicamente, num diretório, sem compartilhar bibliotecas
(que podem ser "linkadas" dinamica ou estaticamente), e alternar entre
versões diferentes envolve um mero redirecionamento de link no sistema
de arquivos. Inclusive tem sistemas operacionais que adotam essa
abordagem como padrão, como por exemplo, os derivados de BSD.
 
    Gilmar> Se sua equipe de desenvolvimento é mais rápida que os
    Gilmar> empacotadores e tem tempo para ficar verificando a versão
    Gilmar> mais recentes de todos os módulos usados todos os dias, que
    Gilmar> bom. Não vejo muitas equipes assim por aí...

Sim, no mundo real, onde rola o dinheiro de verdade e onde o "time to
market" é o fator definitivo para o negócio (em bancos como o Chase
Manhattan e redes como AOL e BBC), as equipes precisam ser ágeis. Não se
trata de "verificar" todo dia, se trata de que as features novas e os
bugs que aparecem para serem resolvidos são fundamentais para o negócio
(isto é, os stakeholders perdem *muito* dinheiro, "tutu",
"money"... capiche?) e *toda hora* (literalmente) aparece um problema
que precisa ser resolvido com um patch ou que revela um bug na
biblioteca.
    
    Gilmar> E quanto à defasagem, sorteie N módulos CPAN (ou escolha um
    Gilmar> conjunto de sua preferência) e verifique a versão mais
    Gilmar> recente do CPAN e do debian unstable.

Você não está entendendo, "ágil" significa que não se pode depender de
esperar nem um dia sequer pela boa vontade dos empacotadores. Além
disso, é bastante complicado uma empresa escolher essa dependência sem
ter um contrato formal em jogo, porque cada segundo se traduz em algumas
centenas de dólares, cabeças precisam rolar se houver algum problema.
    
    Gilmar> Por fim, boa parte do que estamos debatendo faz parte da
    Gilmar> política de cada empresa/organização. O uso de pacotes é bem
    Gilmar> adequado às políticas que tive contato até agora, o que não
    Gilmar> quer dizer que seja solução universal.

A quantos usuários os sistemas dessas organizações atendiam, e qual o
volume de dados processados? Pode até ser possível usar pacotes em
alguns cenários, mas nos cenários que requerem agilidade