A distribuição Debian teste (“testing”)

Para informações básicas aos(às) usuários(as) sobre a distribuição teste (testing), veja a FAQ do Debian.

Uma coisa importante a ser notada, tanto para usuários(as) regulares quanto para desenvolvedores(as), é que as atualizações de segurança da testing não são gerenciadas pela equipe de segurança. Para mais informações veja a FAQ da equipe de segurança.

Esta página cobre, fundamentalmente, os aspectos da testing que são importantes para desenvolvedores(as) Debian.

Como a testing funciona

A distribuição testing é uma distribuição gerada automaticamente. Ela é gerada a partir da distribuição instável (unstable) por um conjunto de scripts que buscam mover pacotes que provavelmente não possuem bugs críticos ao lançamento (release-critical). Eles o fazem de modo a garantir que as dependências dos outros pacotes na testing sempre possam ser satisfeitas.

Um pacote, de uma determinada versão, se moverá para a testing quando ele satisfizer todos os seguintes critérios:

  1. Ele precisa estar na instável (unstable) por 10, 5 ou 2 dias, dependendo da urgência do upload;
  2. Ele precisa estar compilado e atualizado em todas as arquiteturas nas quais ele foi anteriormente compilado na instável (unstable);
  3. Não pode haver nenhum bug crítico (release-critical), o que também se aplica à versão atualmente na testing (veja abaixo para mais informações);
  4. Todas as suas dependências precisam ser satisfeitas, ou pelos pacotes que já estão na testing, ou pelo grupo de pacotes que serão instalados ao mesmo tempo;
  5. A operação de instalação do pacote na testing não deve quebrar qualquer outro pacote na testing (Veja abaixo para mais informações.)

Um pacote que satisfaz as três primeiras condições acima é considerado um candidato válido (valid candidate).

O script de atualização mostra quando cada pacote deve mover-se da instável (unstable) para a testing. A saída é dividida em duas partes:

Dúvidas frequentes

O que são bugs críticos ao lançamento (release-critical), e como eles são contados?

Todos os bugs de severidades altas são considerados críticos ao lançamento por padrão; atualmente, esses bugs são denominados de críticos (critical), graves (grave) e sérios (serious).

Presume-se que tais bugs tenham um impacto nas probabilidades do pacote ser lançado com a versão estável (stable) do Debian: em geral, se um pacote tem bugs críticos ao lançamento, ele não irá para a testing, e consequentemente não será lançado na estável (stable).

A contagem de bugs na testing é constituída de todos os bugs críticos ao lançamento (release-critical) que, marcados para serem aplicados como combinações pacote/versão, ficam disponíveis na testing para lançamento em uma determinada arquitetura.

Como a instalação de um pacote na testing poderia quebrar os outros pacotes?

A estrutura dos repositórios da distribuição é tal que ela pode conter somente uma versão de um pacote; um pacote é definido por seu nome. Assim, quando o pacote-fonte acmefoo é instalado na testing, junto com seus pacotes binários acme-foo-bin, acme-bar-bin, libacme-foo1 e libacme-foo-dev, a versão antiga é removida.

No entanto, a versão mais antiga pode também ter provido um pacote binário com um soname antigo de uma biblioteca, como libacme-foo0. Remover o acmefoo antigo removerá o libacme-foo0, quebrando qualquer pacote que dependa dele.

Evidentemente, isto afeta principalmente pacotes que têm alterações de pacotes binários em versões diferentes (assim sendo, principalmente bibliotecas). No entanto, pacotes nos quais há dependências de versões declaradas com as comparações ==, <= ou << também serão afetados.

Quando os pacotes binários vindos de um pacote-fonte se alteram deste modo, todos os pacotes que dependam das bibliotecas antigas terão que ser atualizados para depender dos binários novos. Como a instalação de tais pacotes na testing quebram todos os pacotes que dependem deles na testing, algum cuidado tem que ser tomado: todos os pacotes dependentes precisam estar atualizados e prontos para serem instalados de modo que eles não se quebrarão e, assim que tudo esteja pronto, geralmente é necessária a intervenção manual do gerenciador de lançamento ou um assistente.

Se você está tendo problemas com grupos complicados de pacotes como estes, contate as listas de discussão debian-devel ou a debian-release para receber ajuda.

Eu ainda não entendo! Os scripts da testing dizem que este pacote é um candidato válido, mas ele ainda não foi para a testing.

Isto tende a acontecer quando, de algum modo direto ou indireto, instalar o pacote vai quebrar algum outro pacote.

Lembre-se de considerar as dependências do seu pacote. Suponha que o seu pacote depende da libtool, ou libltdlX. Seu pacote não irá para a testing até que a versão correta da libtool esteja pronta para ir com ele.

Do mesmo modo, isso não irá ocorrer até que a instalação da libtool não quebre pacotes que já estão na testing. Em outras palavras, até que todos os outros pacotes que dependem da libltdlY (onde Y é a versão anterior) tenham sido recompilados, e todos os seus bugs críticos ao lançamento estiverem corrigidos, etc, nenhum destes pacotes entrará na testing.

É aqui que a saída de texto [compactada com gzip] é útil: ela dá dicas (embora bastante resumidas) de quais pacotes quebram quando um candidato válido é adicionado à testing (veja a referência para desenvolvedores(as) para mais detalhes).

Por que algumas vezes é difícil ter pacotes Architecture: all na testing?

Se o pacote Architecture: all deve ser instalado, ele precisa satisfazer suas dependências em todas as arquiteturas. Se ele depende de determinados pacotes que compilam somente em um conjunto limitado das arquiteturas do Debian, isto não será possível.

No entanto, e por enquanto, a testing ignorará a capacidade de instalação dos pacotes Architecture: all em arquiteturas não-i386. (Isto é um hack grosseiro e eu não estou realmente feliz em ter feito isto, mas que seja. —aj)

Meu pacote está parado porque ele está desatualizado em alguma arquitetura. O que eu devo fazer?

Verifique o estado de seu pacote no banco de dados de logs de construção. Se o pacote não pode ser construído, ele estará marcado como failed (falha); investigue os logs e corrija todos os problemas que foram causados pelas fontes do seu pacote.

Se você notar que alguma arquitetura construiu a versão nova do seu pacote, mas ele não está aparecendo na saída dos scripts da testing, você só precisa ser um pouco mais paciente até que o(a) mantenedor(a) do respectivo buildd faça o upload dos arquivos para o repositório Debian.

Se você notar que algumas arquiteturas não construíram a nova versão de seu pacote, apesar de você ter feito o upload de uma correção para uma falha anterior, o motivo provavelmente é que ele está marcado como esperando por dependências (Dep-Wait). Você também pode ver a lista dos chamados wanna-build states (estados quer construir) para se certificar.

Estes problemas acabam sendo corrigidos eventualmente, mas se você está esperando por um período longo de tempo (digamos, duas semanas ou mais), notifique o(a) mantenedor(a) do buildd do respectivo porte se tal contato estiver documentado nas páginas dos portes, ou notifique a lista de discussão do porte.

Se você explicitamente removeu uma arquitetura da lista Architecture no arquivo de controle (control), e o pacote foi construído para aquela arquitetura anteriormente, você precisa requisitar a remoção, no repositório, do antigo pacote binário para esta arquitetura antes que seu pacote possa fazer a transição para a testing. Você precisa reportar um bug contra ftp.debian.org requisitando remoção de todos os pacotes das arquiteturas removidas do repositório instável (unstable). Geralmente, a lista do porte em questão deve ser informada como forma de cortesia.

Existem algumas exceções? Eu tenho certeza que o acmefoo entrou na testing apesar de não satisfazer todos os requerimentos.

Os(As) gerentes de lançamento podem sobrepujar as regras de dois modos:

Você pode dar um exemplo real e não trivial?

Aqui está um: quando o pacote-fonte apache é instalado na testing, junto com seus pacotes binários apache, apache-common, apache-dev e apache-doc, a versão antiga é removida.

No entanto, todos os pacotes de módulos do Apache dependem de apache-common (>=alguma-coisa), apache-common (<< alguma-coisa), assim esta alteração quebra todas essas dependências. Consequentemente, todos os módulos Apache precisam ser recompilados contra a nova versão do Apache para a testing ser atualizada.

Vamos elaborar mais um pouco: depois que todos os módulos foram atualizados na instável para trabalhar com o novo Apache, os scripts da testing tentam apache-common e descobrem que ele quebra todos os módulos Apache porque eles tem Depends: apache-common (<< a versão atual); e então tentam libapache-foo para descobrir que ele não instala porque ele tem Depends: apache-common (>= a versão nova).

No entanto, posteriormente eles aplicarão uma lógica diferente (algumas vezes isso é requisitado por uma intervenção manual): eles ignorarão o fato de que o apache-common quebra coisas, e continuarão com o que funciona; se isto ainda não funcionar depois que nós fizermos tudo que podíamos, tudo bem, mas talvez isto irá funcionar. Posteriormente eles tentarão todos os pacotes libapache-foo e verificarão se eles realmente funcionam.

Depois que tudo tiver sido tentado, eles verificam quantos pacotes foram quebrados, analisam se isto é melhor ou pior do que havia originalmente, e aceitam tudo ou esquecem tudo. Você verá isto no update_output.txt nas linhas recur:.

Por exemplo:

         recur: [foo bar] baz

basicamente diz que, já tendo descoberto que foo e bar tornam as coisas melhores, eu estou agora tentando baz para ver o que acontece, mesmo sabendo que vai quebrar algo. As linhas do update_output.txt que começam com accepted (aceito) indicam algo que parece tornar as coisas melhores, e linhas skipped (ignorado) indicam algo que deixam as coisas piores.

O arquivo update_output.txt é completamente ilegível!

Isto não é uma questão. ;-)

Vamos pegar um exemplo:

 skipped: cln (0) (150+4)
     got: 167+0: a-40:a-33:h-49:i-45
     * i386: ginac-cint, libginac-dev

Isto significa que se o cln entrar na testing, ginac-cint e libginac-dev tornam-se não instaláveis na testing no i386. Note que as arquiteturas são verificadas em ordem alfabética e que somente os problemas na primeira arquitetura problemática são mostrados — é por isso que a arquitetura alpha é mostrada tão frequentemente.

A linha got inclui o número de problemas na testing nas diferentes arquiteturas (até a primeira arquitetura onde um problema é encontrado — veja acima). i-45 significa que se o cln fosse para a testing, haveria 45 pacotes não-instaláveis na i386. Algumas das entradas acima e abaixo do cln mostram que havia 43 pacotes não-instaláveis na testing, na arquitetura i386 e naquele momento.

A linha skipped: cln (0) (150+4) significa que ainda há 150 pacotes para checar, após o pacote em questão, até que a verificação de todos os pacotes seja completada; e que 4 pacotes já estão planejados para não serem atualizados, pois quebrariam dependências. O (0) é irrelevante, você pode ignorá-lo sem receios.

Observe que há várias verificações de todos os pacotes em uma rodada dos scripts da testing.

Jules Bean organizou inicialmente as questões e respostas frequentemente feitas.

Informações Adicionais

As páginas a seguir fornecem informações adicionais sobre o estado atual da testing e a migração de pacotes da instável para a testing:

Você pode estar interessado em ler um antigo e-mail de explicação. Sua única grande falha é que ele não leva em conta o pool dos pacotes, porque isto foi implementado por James Troup depois que o e-mail foi escrito.

O código da testing está disponível em ftp-master.

Anthony Towns leva os créditos pela implementação da testing.