Corrigida uma série de erros. []s! -- Guilherme de S. Pastore (fatalerror) <gpastore@colband.com.br>
#use wml::debian::template title="A distribuição Debian “testing”" BARETITLE=true
#include "$(ENGLISHDIR)/releases/info"
#use wml::debian::translation-check translation="1.19"
<p>Para informações básicas, orientadas ao usuário, sobre a distribuição
testing, veja a <a href="$(DOC)/FAQ/ch-ftparchives#s-testing">FAQ do
Debian</a>.</p>
<p>Uma coisa importantes para notar, para ambos usuários regulares e
desenvolvedores, é que as atualizações de segurança <strong>não são
gerenciadas pela equipe de segurança</strong>. Para mais informações
veja a <a href="../security/faq#testing">FAQ da Equipe de Segurança</a>.</p>
<p>Esta página cobre primariamente os aspectos da "testing" importantes para
desenvolvedores Debian.</p>
<h2>Como a "testing" funciona</h2>
<p>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.</p>
<p>Uma versão particular de um pacote irá mover-se para a testing quando ele
satisfizer todos os seguintes critérios:</p>
<ol>
<li>Ele precisa estar na unstable por 10, 5 ou 2 dias, dependendo da
urgência do upload;</li>
<li>Ele precisa estar compilado e atualizado em todas as arquiteturas
nas quais ele foi anteriormente compilado na unstable;</li>
<li>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
<a href="#faq">mais informações</a>);</li>
<li>Todas as suas dependências precisam ser satisfeitas <em>ou</em>
pelos pacotes que já estão na "testing" <em>ou</em> pelo grupo de
pacotes que serão instalados ao mesmo tempo;</li>
<li>A operação de instalação do pacote na "testing" não deve quebrar
qualquer outro pacote na "testing" (Veja abaixo para
<a href="#faq">mais informações</a>.)</li>
</ol>
<p>Um pacote que satisfaz as três primeiras condições são considerados
<q>Candidatos Válidos</q>.</p>
<p>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:</p>
<ul>
<li>As <a href="http://ftp-master.debian.org/testing/update_excuses.html";>\
justificativas de atualização (update excuses)</a>
[<a href="http://ftp-master.debian.org/testing/update_excuses.html.gz";>\
gzipadas</a>]:
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
</li>
<li>A <a href="http://ftp-master.debian.org/testing/update_output.txt";>\
saída de atualização (update output) </a>
[<a href="http://ftp-master.debian.org/testing/update_output.txt.gz";>\
gzipada</a>]:
a saída completa, crú dos scripts da "testing" conforme eles passam
pelos candidatos
</li>
</ul>
<h2><a name="faq">Questões Feitas/Respondidas Freqüentemente</a></h2>
<h3><q>O que são bugs críticos ao lançamento (release-critical), e como
eles são contados?</q></h3>
<p>Todos os bugs de algumas severidades altas são considerados
<em><a href="http://bugs.debian.org/release-critical/";>críticos ao
lançamento</a></em> por padrão; atualmente, estas são
<strong>crítico</strong>, <strong>grave</strong> e <strong>sério</strong>.</p>
<p>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".</p>
<p>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
<strong><current_release_name></strong> ou
<strong><current_testing_name></strong> não serão contados. No entanto,
bugs com a tag <strong>sid</strong> serão contados.</p>
<h3><q>Como instalar um pacote na "testing" poderia quebrar os outros
pacotes?</q></h3>
<p>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 <tt>acmefoo</tt> é instalado na "testing", junto com
seus pacotes binários <tt>acme-foo-bin</tt>, <tt>acme-bar-bin</tt>,
<tt>libacme-foo1</tt> e <tt>libacme-foo-dev</tt>, a versão antiga é
removida.</p>
<p>No entanto, a versão mais antiga pode também ter provido um pacote
binário com um soname antigo de uma biblioteca, como <tt>libacme-foo0</tt>.
Remover o <tt>acmefoo</tt> antigo removerá o <tt>libacme-foo0</tt>, quebrando
qualquer pacote que dependa dele.</p>
<p>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 variedades ==, <= ou << também serão afetados.</p>
<p>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 prontos para serem instalados de modo que eles não estejam
quebrados e, assim que tudo esteja pronto, a intervenção manual do gerenciador
de lançamento ou um assistente geralmente é necessária.</p>
<p>Se você está tendo problemas com grupos complicados de pacotes como estes,
contate a debian-devel ou a debian-release para receber ajuda.</p>
<h3><q>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".</q></h3>
<p>Isto tende a acontecer quando de algum modo, direto ou indireto,
instalar o pacote vai quebrar algum outro pacote.</p>
<p>Lembre-se de considerar as dependências do seu pacote. Suponha que
o seu pacote depende da libtool, ou libltdl<var>X</var>. Seu pacote não
irá para a "testing" até que a versão correta da libtool esteja pronta
para ir com ele.</p>
<p>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 libltdl<var>Y</var> (aonde <var>Y</var> é a
versão anterior) tenham sido recompilados, e todos os seus bugs crítcos ao
lançamento estiverem corrigidos, etc, nenhum destes pacotes entrará na
"testing".</p>
<p>É aqui que a <a href="http://ftp-master.debian.org/testing/update_output.txt";>\
saída de texto</a>
[<a href="http://ftp-master.debian.org/testing/update_output.txt.gz";>gzipada</a>]
é útil: ela dá dicas (embora bastante resumidas) de quais pacotes quebram
quando um candidato válido é adicionado à "testing".</p>
<h3><q>Por que algumas vezes é difícil ter pacotes <kbd>Architecture: all</kbd>
na "testing"?</q></h3>
<p>Se o pacote <kbd>Architecture: all</kbd> deve ser instalado, ele precisa
satisfazer suas dependências em <strong>todas</strong> as arquiteturas.
Se ele depende de dados pacotes que compilam somente em um conjunto
limitado das arquiteturas do Debian, isto não será possível.</p>
<p>No entanto, por enquanto, a "testing" irá ignorar a instalabilidade dos
pacotes <kbd>Architecture: all</kbd> em arquiteturas não-i386. (<q>Isto
é um hack grosseiro e eu não estou realmente feliz em ter feito isto,
mas aí vai</q> --aj)</p>
<h3><q>Meu pacote está parado porque ele está desatualizado em alguma
arquitetura. O que eu devo fazer?</q></h3>
<p>Verifique o estado de seu pacote no
<a href="http://buildd.debian.org/build.php";>banco de dados de logs de
construção</a>. Se o pacote não pode ser compilado, ele estará marcado como
<em>failed</em>; investigue os logs e corrija todos os problemas
que foram causados pelas fontes do seu pacote.</p>
<p>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 mantenedor do
respectivo buildd faça o upload dos arquivos para o repositório Debian.</p>
<p>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 <a href="http://buildd.debian.org/stats/";>wanna-build states</a>
(estados quer-construir) para se certificar.</p>
<p>Estes problemas geralmente são corrigidos eventualmente, mas se você
está esperando por um período longo de tempo (digamos, duas semanas ou mais),
notifique o mantenedor do buildd do respectivo porte se tal endereço estiver
documentado nas <a href="$(HOME)/ports/">páginas dos portes</a>, ou a lista
de discussão do porte.</p>
<h3><q>Há alguma exceção? Eu tenho certeza que o <tt>acmefoo</tt>
entrou na "testing" apesar de não satisfazer todos os requerimentos.</q></h3>
<p>O gerente de lançamento pode sobrepujar as regras de dois modos:</p>
<ul>
<li>Ele pode decidir que a quebra causada pela instalação de uma nova
biblioteca irá tornar as coisas melhores ao invés de piores, e deixá-la
entrar na "testing" junto com suas dependências.</li>
<li>Ele também pode remover manualmente pacotes da "testing" que
ficariam quebrados, para que o novo material possa ser instalado.</li>
</ul>
<h3><q>Você pode dar um exemplo real, não-trivial?</q></h3>
<p>Aqui está um: quando o pacote fonte <tt>apache</tt> é instalado na
"testing", junto com seus pacotes binários <tt>apache</tt>,
<tt>apache-common</tt>, <tt>apache-dev</tt> e <tt>apache-doc</tt>, a
versão antiga é removida.</p>
<p>No entanto, todos os pacotes de módulos do Apache dependem de
<code>apache-common (>=<var>alguma-coisa</var>), apache-common
(<< <var>alguma-coisa</var>)</code>, assim esta alteração quebra
todas estas dependências. Conseqüentemente, todos os módulos Apache
precisam ser recompilados contra a nova versão do Apache para a
"testing" ser atualizada.</p>
<p>Vamos elaborar mais um pouco: depois que todos os módulos foram
atualizadas na "instável" para trabalhar com o novo Apache, os scripts
da "testing" tentam <tt>apache-common</tt> e descobrem que ele quebra
todos os módulos Apache porque eles tem <code>Depends: apache-common
(<< <var>a versão atual</var>)</code>, e então tentam
<tt>libapache-<var>foo</var></tt> para descobrir que ele não instala
porque ele tem <code>Depends: apache-common (>= <var>a versão
nova</var>)</code>.</p>
<p>No entanto, posteriormente eles irão aplicar uma lógica diferente
(algumas vezes pedidas por uma intervenção manual): eles irão ignorar o
fato que o <tt>apache-common</tt> quebra coisas, e continuar indo com as
coisas que funcionam; se isto ainda não funcionar depois que nós fizermos
tudo que nós podiamos, muito mal, mas talvez isto <strong>irá</strong>
funcionar. Posteriormente eles tentarão todos os pacotes
<tt>libapache-<var>foo</var></tt> e verificar se eles realmente funcionam.</p>
<p>Depois que tudo tiver sido tentado, eles verificam quantos pacotes
foram quebrados, analisam se isto é melhor ou pior que o que havia
originalmente e aceitar tudo ou esquecer sobre isto. Você verá isto no
<tt>update_output.txt</tt> nas linhas "<code>recur:</code>".</p>
<p>Por exemplo::</p>
<pre>
recur: [<var>foo</var> <var>bar</var>] <var>baz</var>
</pre>
<p>basicamente diz <q>já tendo descoberto que <var>foo</var> e
<var>bar</var> torna as coisas melhores, Eu estou agora tentando
<var>baz</var> para ver o que acontece, apesar disto quebrar coisas</q>. As
linhas do <tt>update_output.txt</tt> que começam com "<code>accepted</code>"
indicam coisas que parecem tornar as coisas melhores, e linhas
"<code>skipped</code>" deixam as coisas piores.</p>
<h3><q>O arquivo <tt>update_output.txt</tt> é completamente ilegível!</q></h3>
<p>Isto não é uma questão. ;-)</p>
<p>Vamos pegar um exemplo:</p>
<pre>
skipped: cln (0) (150+4)
got: 167+0: a-40:a-33:h-49:i-45
* i386: ginac-cint, libginac-dev
</pre>
<p>Isto significa que se o <tt>cln</tt> entrar na "testing",
<tt>ginac-cint</tt> e <tt>libginac-dev</tt> tonram-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
freqüentemente.</p>
<p>A linha "got" inclui o número de problemas na "testing" nas
arquiteturas diferentes (até a primeira arquitetura onde um problema é
encontrado -- veja acima). "i-45" significa que se o <tt>cln</tt> fosse
para a "testing", haveria 45 pacotes não-instaláveis na i386. Algumas
das entradas acima e abaixo do <tt>cln</tt> mostram que havia 43
pacotes não-instaláveis na "testing" nesta arquitetura naquele momento.</p>
<p>A linha "skipped: cln (0) (150+4)" significa que ainda há 150 pacotes para
checar após este pacote até esta verficação de todos os pacotes ser completada,
e que 4 pacotes que não vão ser planejados para atualização pois quebrariam
dependências já foram encontrados. O "(0)" é irrelevante, você pode
ignorá-lo seguramente.</p>
<p>Note que há várias verificações de todos os pacotes em uma rodada dos
scripts da "testing".</p>
<p><i>Jules Bean montou inicialmente as questões freqüentemente feitas e
as respostas.</i></p>
<h2>Informações Adicionais</h2>
<p>Estes scripts também detectam bugs que podem ser descritos como
horrivelmente-severos-não-deveriam-estar-aqui-pra-começo-de-conversa.
Esses são todos ofensas 'nem mesmo se preocupe em considerar este pacote
para inclusão', que irão (espera-se) desaparecer durante o congelamento,
e dias de caça aos bugs e assim por diante.
<br>
Há listas destes bugs para as três distribuições:
<ul>
<li><a href="http://ftp-master.debian.org/testing/testing_probs.html";>problemas na testing</a></li>
<li><a href="http://ftp-master.debian.org/testing/unstable_probs.html";>problemas na instável</a></li>
<li><a href="http://ftp-master.debian.org/testing/stable_probs.html";>problemas na estável</a></li>
</ul>
<p>Além disso, há algumas estatísticas sobre pacotes binários que estão desatualizados na
<a href="http://ftp-master.debian.org/testing/testing_outdate.txt";>testing</a>,
<a href="http://ftp-master.debian.org/testing/stable_outdate.txt";>estável</a> e
<a href="http://ftp-master.debian.org/testing/unstable_outdate.txt";>instável</a>.</p>
<p>Björn Stenberg escreveu um <a href="http://bjorn.haxx.se/debian/";>\
front-end</a> para ajudá-lo a encontrar os motivos pelo qual pacotes estão
sendo mantidos foram da testing.</p>
<p>Você pode estar interessado em ler uma
<a href="http://lists.debian.org/debian-devel-0008/msg00906.html";>mensagem
de explicação</a> antiga. Sua única falha é que ela não leva o pool dos
pacotes em conta, porque ele foi implementado pelo James Troup depois
que ela foi escrita.</p>
<p>O código da testing está disponível em
<a href="http://ftp-master.debian.org/testing/update_out_code/";>ftp-master</a>.</p>
<p><i>Anthony Towns leva os créditos pela implementação da testing.</i></p>
Attachment:
pgp1KYcybxrFv.pgp
Description: PGP signature