Debian/APT- Alguns cuidados com os repósitorios

Aqui vou mostrar o que pode acontecer com nosso sistema se não tomarmos alguns cuidados com nossos repositórios. Recomendo essa leitura a usuários que já tenham ou tiveram contato com APT.

[ Hits: 17.569 ]

Por: Fabio Maran em 27/11/2007 | Blog: http://movimentolivre.zip.net


Introdução



Vou ser direto, não abordarei a história do APT ou como funciona, pois não é a prioridade aqui. Recomendo a leitura para quem já teve ou tem contato com APT.

Vamos ao que interessa!

Digamos que usamos a versão stable (etch) em nosso sistema, mas gostaríamos de buscar pacotes testing (lenny) e unstable, para isso precisaríamos editar o arquivo /etc/apt/sources.list e adicionarmos os repositórios escolhidos.

Mas antes disso devemos tomar algumas providências para não haver conseqüências desastrosas.

Vou dar um exemplo:

Depois de adicionarmos as fontes do testing e do unstable, veja o que vai acontecer:

# apt-get update
# apt-get install pacote


Primeiro serão baixadas as relações de pacotes do stable, de segurança e do testing. Depois demos a ordem para instalar um novo pacote, como temos vários repositórios, o APT irá instalar a versão mais nova do pacote. É quase certo que a versão mais nova do pacote estará na testing. Assim podemos afirmar que mais nenhum pacote virá do stable. Daí você me pergunta mais???

Aí que está, se nenhum pacote vir mais do stable, estaremos contaminando nosso sistema aos poucos, além de que se misturarmos pacotes de releases diferentes podem acontecer incompatibilidades.

Conseqüências piores viriam se déssemos um upgrade no sistema, veja:

# apt-get upgrade

Neste caso o nosso stable passaria de vez a ser testing, pois o APT sempre busca versões mais recentes. E não adiantaria retirarmos o repositório testing depois de termos feito isso, pois o APT concluirá que os pacotes existentes são mais recentes do que os existentes no repositórios stable.

    Próxima página

Páginas do artigo
   1. Introdução
   2. Solução
Outros artigos deste autor

Desvendando os filesystems

DansGuardian: Filtrando o acesso a Web

Virtualização de sistemas

Samba: Integração com ClamAV e outras coisas úteis

Shell script: *, [], {}, ????, como utilizá-los?

Leitura recomendada

Utilizando certificados e-CNPJ e e-CPF no Linux

Configuração de teclado e dispositivos de entrada em geral a partir do HAL no Xorg 1.5 e superiores

Trabalhando com shell e variáveis de ambiente

Como instalar e configurar duas ou mais distros

Instalação e configuração do Apache2 com SSL e MOD_JK no Solaris

  
Comentários
[1] Comentário enviado por nicolo em 27/11/2007 - 08:37h

Esse problema tem sido indicado em vários posts, mas com solução mais conservadora. A priorização será útil se os pacotes não forem os mesmos, caso contrário vai ocorrer sempre o de prioridade máxima. Não é boa idéia misturar o stable com o testing, mesmo priorizando. O testing é papel no vento, chega a ser incompatível com ele mesmo, duas semanas mais tarde. Depois que misturar vai dar nó.
Precisa deixar só o stable, desinstalar tudo que for incompatível e instalar de novo.

Repíto o que já postei;
Só instale um repositório misturado se você precisa de um pacote que não há no stable. Não há como priorizar. O pacote pode exigir uma versão diferente de bibliotecas, atualiza ou não instala, e vai ocorrer o risco.
Depois de instalar volte ao stable.
Gostei do artigo para chamar atenção do problema.
Não concordo com a solução indicada, é temerária.

[2] Comentário enviado por tjpp em 27/11/2007 - 09:40h

Eu uso a testing direto, e ainda assim alguns pacotes da instável. Eu concordo com o nicolo, sobre a estabilidade da solução acima. Eu prefiro recompilar os pacotes da distribuição mais atual. Eu fiz isto recentemente pois o nautilus está com um bug, na testing, que já foi corrigido na instável, mas que pode demorar a chegar na testing porque o pacote não compila em outras arquiteturas.

Eu descrevi o que fiz em http://profs.if.uff.br/tjpp/blog/entradas/bug-do-nautilus-no-lenny-backport .

[3] Comentário enviado por Gilmar_GNU/Slack em 27/11/2007 - 09:43h

Mais nesse caso ai os pacotes unstable, estariam sendo usados como teste ,não e isso !
Pois isso poderia realmente dar em merda se colocasse esse pacotes no seu sistem.
o nó seria muito grande.
E ainda mais que teria o trabalho de esolher os repositórios a serem excluidos!

[4] Comentário enviado por Kondor-rj em 27/11/2007 - 09:50h

Bem, por causa disso as distros baseadas no Debian como o Ubuntu têm base por exemplo o Debian Sid.

[5] Comentário enviado por removido em 27/11/2007 - 10:07h

Bom o seu artigo!

[6] Comentário enviado por elfou em 27/11/2007 - 10:36h

Bom conteudo seu artigo cara.

[7] Comentário enviado por volcom em 27/11/2007 - 13:47h

Legal,

Mesmo com os prós e contras...acho muito útil, pois assim não correria o risco de afetar o sistema com um todo!

Vou testar a opção de indicar a prioridade de somente alguns pacotes para instalação.

Abraço e parabens

[8] Comentário enviado por maran em 27/11/2007 - 23:07h

É isso ais acho que esses contras aii não foram muito bem explicados, muito sem base pois eu mostro a solução de como não misturar e quem criticou ja falou em misturar releases.Bom pessoas que estao em dia com o sistema e como ele funcionam sabe como ou quando misturar alguma coisa...

Bom gostaria de criticas mais explicativas, e não falando já em desastre....

Te Mais....


[9] Comentário enviado por agk em 02/01/2008 - 21:28h

E o back-ports?
É uma boa pra quem quer usar stable e ter os programas mais novos sem precisar ficar fazendo updates diários que o testing e sid tem.

[10] Comentário enviado por maran em 02/01/2008 - 21:34h

backports???
segue o link
http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=7412

hehe Te Mais...


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts