__
Ein Grund zum Feiern: Die PC Praxis ermittelt zwischen 10 grossen
Mailprovidern WEB.DE FreeMail als Testsieger http://f.web.de/?mc=021190#use wml::debian::template title="A distribuição Debian “testing”" BARETITLE=true
#include "$(ENGLISHDIR)/releases/info"
#use wml::debian::translation-check translation="1.19"
Para informações básicas, orientadas ao usuário, sobre a distribuição
testing, veja a FAQ do
Debian.
Uma coisa importantes para notar, para ambos usuários regulares e
desenvolvedores, é que as atualizações de segurança 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 primariamente os aspectos da "testing" importantes para
desenvolvedores Debian.
Como a "testing" funciona
A distribuição "testing" é uma distribuição gerada automaticamente.
Ela é gerada da distribuição "instável" por um conjunto de scripts que
tentam mover pacotes que provavelmente não possuem bugs importantes.
Eles o fazem de modo a certificar-se que as dependências dos outros pacotes
na testing sempre podem ser satisfeitas.
Uma versão particular de um pacote irá mover-se para a testing quando ele
satisfizer todos os seguintes critérios:
Ele precisa estar na unstable por 10, 5 ou 2 dias, dependendo da
urgência do upload;
Ele precisa estar compilado e atualizado em todas as arquiteturas
nas quais ele foi anteriormente compilado na unstable;
Ele precisa ter menos bugs críticos para o lançamento (release-critical)
ou o mesmo número que a versão atualmente na "testing" (veja abaixo para
mais informações);
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;
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 são considerados
Candidatos Válidos.
O script de atualização mostra quando cada pacote deve mover-se da
"instável" para a "testing". A saída é dividida em duas partes:
As http://ftp-master.debian.org/testing/update_excuses.html";>\
justificativas de atualização (update excuses)
[http://ftp-master.debian.org/testing/update_excuses.html.gz";>\
gzipadas]:
listam todos as versões candidatas dos pacotes e o estado básico de sua
propagação para a "testing"; ele é um pouco mais curto e mais amigável
A http://ftp-master.debian.org/testing/update_output.txt";>\
saída de atualização (update output)
[http://ftp-master.debian.org/testing/update_output.txt.gz";>\
gzipada]:
a saída completa, crú dos scripts da "testing" conforme eles passam
pelos candidatos
Questões Feitas/Respondidas Frequentemente
O que são bugs críticos ao lançamento (release-critical), e como
eles são contados?
Todos os bugs de algumas severidades altas são considerados
http://bugs.debian.org/release-critical/";>críticos ao
lançamento por padrão; atualmente, estas são
crítico, grave e sério.
Presume-se que tais bugs tenham um impacto nas probabilidades do pacote
ser lançado com a versão estável do Debian: em geral, se um pacote tem bugs
críticos ao lançamento, ele não irá para a "testing", e conseqüentemente
não irá ser lançado na "estável".
A contagem de bugs "testing" de um pacote é considerada como
aproximadamente a contagem de bugs no último momento no qual a versão na
"testing" era a mesma da "instável". Os bugs com tag
ou
não serão contados. No entanto,
bugs com a tag sid serão contados.
Como instalar um pacote na "testing" poderia qubrar 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 tem 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 variedads ==, <= ou << também serão afetados.
Quando os pacotes binários vindos de um pacote fonte se alteram deste modo,
todos os pacotes que dependem das bibliotecas antigas tem 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 pronto
