Introdução curta ao apt-pinning

Versão 1.0
Autor: Falko Timme

1 Nota preliminar

Este artigo é uma visão geral curta sobre como usar o apt‑pinning em Debian e distribuições baseadas em Debian (como Ubuntu). O apt‑pinning permite ter várias releases disponíveis no sistema (por exemplo: stable, testing e unstable) e especificar de qual release instalar cada pacote. Assim, você pode manter um sistema baseado principalmente em stable e, ao mesmo tempo, instalar pacotes mais recentes de testing ou unstable (ou de repositórios de terceiros) quando necessário.

Não há garantia de que isso funcionará no seu ambiente; sempre teste em uma máquina de staging.

Estou usando um sistema Debian Lenny (stable) como exemplo. Vou explicar o apt‑pinning com base no pacote phpmyadmin, que, no momento deste texto, está disponível em três versões diferentes nas releases stable, testing e unstable — veja: http://packages.debian.org/search?keywords=phpmyadmin&searchon=names&suite=all§ion=all

• lenny (stable): version 4:2.11.8.1-5
• squeeze (testing): version 4:3.1.2-2
• sid (unstable): version 4:3.1.3-1

2 Meu /etc/apt/sources.list

Adicionei os repositórios testing e unstable ao meu /etc/apt/sources.list para que ele fique como a seguir.

vi /etc/apt/sources.list

deb http://volatile.debian.org/debian-volatile lenny/volatile main
deb-src http://volatile.debian.org/debian-volatile lenny/volatile main

## Lenny / Stable
deb http://ftp2.de.debian.org/debian/ lenny main
deb-src http://ftp2.de.debian.org/debian/ lenny main

deb http://security.debian.org/ lenny/updates main
deb-src http://security.debian.org/ lenny/updates main

## Squeeze / Testing
deb http://ftp2.de.debian.org/debian/ squeeze main
deb-src http://ftp2.de.debian.org/debian/ squeeze main

deb http://security.debian.org/ squeeze/updates main
deb-src http://security.debian.org/ squeeze/updates main

## Sid / Unstable
deb http://ftp2.de.debian.org/debian/ sid main
deb-src http://ftp2.de.debian.org/debian/ sid main

Abra /etc/apt/apt.conf:

vi /etc/apt/apt.conf

… e coloque a seguinte linha nele:

APT::Cache-Limit "100000000";

(Se não, você pode obter um erro como este ao executar apt-get update:)

E: Dynamic MMap ran out of room

Em seguida execute:

apt-get update

para atualizar o banco de dados de pacotes.

Com a versão atual do APT, ele tende a instalar a versão mais nova disponível de um pacote, o que normalmente vem de unstable ou testing — isso pode deixar o sistema inconsistente. Com apt‑pinning podemos definir prioridades para que um pacote seja instalado de unstable/testing apenas quando não houver versão adequada em stable (ou quando quisermos explicitamente).

Podemos verificar as prioridades atuais do APT com:

apt-cache policy

Exemplo de saída (reduzida):

server1:~# apt-cache policy  
 Package files:  
 100 /var/lib/dpkg/status   
     release a=now  
  500 http://volatile.debian.org lenny/volatile/main Packages  
     release o=volatile.debian.org,a=stable,l=debian-volatile,c=main  
     origin volatile.debian.org  
  500 http://ftp2.de.debian.org sid/main Packages  
     release o=Debian,a=unstable,l=Debian,c=main  
     origin ftp2.de.debian.org  
  500 http://security.debian.org squeeze/updates/main Packages  
     release v=None,o=Debian,a=testing,l=Debian-Security,c=main  
     origin security.debian.org  
  500 http://ftp2.de.debian.org squeeze/main Packages  
     release o=Debian,a=testing,l=Debian,c=main  
     origin ftp2.de.debian.org  
  500 http://security.debian.org lenny/updates/main Packages  
     release v=5.0,o=Debian,a=stable,l=Debian-Security,c=main  
     origin security.debian.org  
  500 http://ftp2.de.debian.org lenny/main Packages  
     release v=5.0,o=Debian,a=stable,l=Debian,c=main  
     origin ftp2.de.debian.org  
 Pinned packages:  
server1:~#

Como vê, stable, testing e unstable têm a mesma prioridade (500), o que faz o APT preferir a versão mais nova disponível. No caso do phpmyadmin, a versão candidata é a 4:3.1.3-1 (unstable):

apt-cache policy phpmyadmin

Exemplo:

server1:~# apt-cache policy phpmyadmin  
 phpmyadmin:  
   Installed: (none)  
   Candidate: 4:3.1.3-1  
   Version table:  
     4:3.1.3-1 0  
        500 http://ftp2.de.debian.org sid/main Packages  
     4:3.1.2-2 0  
        500 http://ftp2.de.debian.org squeeze/main Packages  
     4:2.11.8.1-5 0  
        500 http://ftp2.de.debian.org lenny/main Packages  
server1:~#

A linha Candidate mostra a versão que seria instalada.

Como funcionam prioridades (P)

As prioridades são explicadas em man 5 apt_preferences. Em resumo:

• P > 1000: força instalação até mesmo se for downgrade.
• 990 < P <= 1000: força instalação mesmo que não venha da release alvo, exceto se a versão instalada for mais nova.
• 500 < P <= 990: instala a versão a menos que exista versão da release alvo ou a instalada seja mais recente.
• 100 < P <= 500: instala a versão a menos que exista versão de outra distribuição com prioridade maior ou a instalada seja mais recente.
• 0 < P <= 100: instala somente se não houver versão instalada.
• P < 0: impede a instalação da versão.

Exemplo prático: forçar stable por padrão e usar testing só para phpmyadmin

Crie um ficheiro em /etc/apt/preferences.d/10pin-stable:

Package: *
Pin: release a=stable
Pin-Priority: 700

Package: phpmyadmin
Pin: release a=testing
Pin-Priority: 800

Explicação rápida: a primeira regra dá prioridade maior (700) a pacotes de stable para a maioria dos pacotes. A segunda regra indica que, para phpmyadmin, a release testing deve ter prioridade 800 — portanto, ele escolherá a versão de testing para esse pacote específico.

Depois execute:

apt-get update
apt-cache policy phpmyadmin

e verifique a Candidate.

Alternativas e quando o apt-pinning falha

• Alternativa: usar backports ou repositórios PPA (no Ubuntu) para obter versões selecionadas de forma mais controlada.
• Alternativa: compilar o pacote localmente (deb) ou usar containers para isolar versões não‑estáveis.

Quando apt‑pinning pode falhar:

• Dependências incompatíveis entre versões (resolve tudo, mas pode puxar muitas dependências de testing/unstable).
• Misturar muitas releases sem testar pode levar a conflitos e quebrar a instalação de pacotes críticos.

Mini‑metodologia de implementação segura

1. Teste em staging: clone a configuração e execute as atualizações.
2. Defina prioridades conservadoras (ex.: stable = 700).
3. Pino por pacote quando possível (evite dar prioridade alta globalmente a testing/unstable).
4. Atualize e verifique apt-cache policy e apt-get -s upgrade (simulação).
5. Faça backup de /etc/apt/ e de listas de pacotes: dpkg –get-selections > before.txt.

Checklist por função

• Administrador de sistemas:

  • Verificar sources.list e arquivos em preferences.d.
  • Testar em staging.
  • Validar dependências antes de aplicar em produção.

• Desenvolvedor / QA:

  • Confirmar que a versão do pacote atende aos requisitos de API.
  • Testar o pacote num ambiente isolado (container/VM).

Fact box — números e caminhos importantes

• Arquivos principais: /etc/apt/sources.list, /etc/apt/apt.conf, /etc/apt/preferences.d/*.
• Cache limit sugerido: 100000000 (valor usado no exemplo).
• Comandos úteis: apt-get update, apt-cache policy, apt-get -s upgrade (simulação), dpkg –get-selections.

Fluxo de decisão (Mermaid)

flowchart TD
  A[Precisa de um pacote mais novo?] -->|Não| B[Usar stable]
  A -->|Sim| C[Existe backport ou PPA?]
  C -->|Sim| D[Usar backport/PPA]
  C -->|Não| E[Pin por pacote para testing/unstable]
  E --> F[Testar em staging]
  F --> G[Aprovar / Implementar em produção]

Dicas práticas

• Prefira pinos por pacote em vez de elevar prioridade globalmente.
• Use apt-get -s upgrade para simular atualizações antes de aplicar.
• Monitore registros de apt e mantenha snapshots/backup de VMs.

Resumo

O apt‑pinning é uma ferramenta poderosa para administrar pacotes quando múltiplas releases estão configuradas no sistema. Use prioridades para controlar de onde os pacotes vêm, prefira pinos por pacote, teste sempre em staging e mantenha backups antes de alterações.

Importante: mudanças de prioridades podem causar atualizações massivas de dependências — planeje e teste.

Критерии приёмки

• A configuração deve permitir instalar phpmyadmin da release desejada sem alterar globalmente a origem dos demais pacotes.
• apt-cache policy mostra a Candidate esperada.
• Simulações apt-get -s upgrade não mostram conflitos inesperados.

Fim.