Capítulo 6. Os arquivos Debian

Índice

6.1. Quantas distribuições Debian existem?
6.2. O que são esses nomes como etch, lenny, etc.?
6.2.1. Quais outros nomes de código foram usados no passado?
6.2.2. De onde estes nomes de código vieram?
6.3. E acerca de "sid"?
6.4. O que é que directório stable contém?
6.5. O que é que a distribuição testing contém?
6.5.1. Então e a "testing"? Como é 'congelada'?
6.6. O que é que a distribuição unstable contém?
6.7. O que são todos aqueles directórios nos arquivos Debian?
6.8. O que são esses directórios dentro de dists/stable/main?
6.9. Onde está o código fonte?
6.10. O que é o directório pool?
6.11. O que é "incoming"?
6.12. Como é que Eu configuro o meu próprio repositório apropriado ao apt?

6.1. Quantas distribuições Debian existem?

Existem três distribuições principais: a distribuição "stable", a distribuição "testing", e a distribuição "unstable". A distribuição "testing" é por vezes 'congelada' (veja Secção 6.5.1, “Então e a "testing"? Como é 'congelada'?”). A parte destas. existe a distribuição "oldstable" (que é aquela anterior a "stable"), e a distribuição "experimental".

Experimental é usada para pacotes que ainda estão em desenvolvimento, e com um alto risco de quebrar o seu sistema. É usada por desenvolvedores que gostam de estudar e testar software de ponta. Os utilizadores não devem usar pacote de lá,pois podem ser perigosos e causar danos até às pessoas com muita experiência.

Veja Capítulo 3, Escolher uma distribuição Debian para ajuda a escolher uma distribuição Debian.

6.2. O que são esses nomes como etch, lenny, etc.?

Eles são apenas "nomes-de-código". Quando uma distribuição Debian está em estado de desenvolvimento, não tem um número de versão mas apenas um nome de código. O objectivo destes nomes de código é facilitar o espelhar das distribuições Debian (se o directório real como unstable subitamente mudasse o seu nome para stable, muita coisa teria de ser desnecessariamente descarregada de novo).

Actualmente, stable é um link simbólico para bullseye (isto é, Debian GNU/Linux 11) e testing é um link simbólico para bookworm. Isto significa que bullseye é a distribuição estável actual e bookworm é a distribuição de testes actual.

unstable é uma ligação simbólica para sid, pois sid é sempre a distribuição instável (veja Secção 6.3, “E acerca de "sid"?”).

6.2.1. Quais outros nomes de código foram usados no passado?

Para além de bullseye e bookworm, outros nomes de código já foram usados e são: buzz para lançamento 1.1, rex para lançamento 1.2, bo para lançamento 1.3.x, hamm para lançamento 2.0, slink para lançamento 2.1, potato para lançamento 2.2, woody para lançamento 3.0, sarge para lançamento 3.1, etch para lançamento 4.0, lenny para lançamento 5.0, squeeze para lançamento, 6.0 wheezy para lançamento 7, jessie para lançamento 8, stretch para lançamento 9, buster para lançamento 10.

6.2.2. De onde estes nomes de código vieram?

Até agora têm sido personagens retiradas dos filmes "Toy Story" da Pixar.

  • buzz (Debian 1.1) era o homem espacial Buzz Lightyear,

  • rex (Debian 1.2) era o tiranossauro,

  • bo (Debian 1.3) era Bo Peep, a rapariga que cuidava do carneiro,

  • hamm (Debian 2.0) era o porco mealheiro,

  • slink (Debian 2.1) era Slinky Dog, o cão brinquedo,

  • potato (Debian 2.2) era, pois claro, o Sr. Batata,

  • woody (Debian 3.0) era o cowboy,

  • sarge (Debian 3.1) era o sargento do Exército de Homens Verdes de Plástico,

  • etch (Debian 4.0) era o brinquedo quadro-branco (Etch-a-Sketch),

  • lenny (Debian 5.0) era os binóculos de brincar,

  • squeeze (Debian 6) era o nome dos aliens de três-olhos,

  • wheezy (Debian 7) era o pinguim de borracha com o laço vermelho,

  • jessie (Debian 8) era a cowgirl cantora,

  • stretch (Debian 9) era o polvo de borracha com ventosas nos oito tentáculos,

  • buster (Debian 10) era o cão de estimação do Andy.

  • bullseye (Debian 11) era o cavalo de maneira do Woody.

  • bookworm (Debian 12) era a minhoca verde brinquedo com uma lanterna embutida que adora ler livros.

  • trixie (Debian 13) era o triceratop azul de plástico.

  • sid era o rapaz mau, vizinho do lado que partia todos os brinquedos.

The decisão de usar nomes do Toy Story foi tomada por Bruce Perens que era, na altura, o líder do Projecto Debian e estava também a trabalhar na Pixar, a companhia que produziu os filmes.

6.3. E acerca de "sid"?

sid ou unstable é o local onde a maioria dos pacotes são inicialmente colocados. Nunca será lançada directamente, porque os pacotes que estão para ser lançados terão que primeiro ser incluídos em testing, de modo a serem lançados em stable mais tarde. A sid contêm pacotes para ambas arquitecturas lançadas e não lançadas.

O nome "sid" também vem do filme de animação "Toy Story": Sid era o rapaz vizinho que destruía os brinquedos :-)

[2]

6.4. O que é que directório stable contém?

  • stable/main/: Este directório contém os pacotes que constituem formalmente o lançamento mais recente do sistema Debian GNU/Linux .

    Este pacotes todos cumprem com as Debian Free Software Guidelines, e são utilizáveis e distribuíveis livremente.

  • stable/non-free/: Este directório contém pacotes cuja distribuição é restrita num modo que requer que os distribuidores tenham em conta os requerimentos de copyright especificados.

    Por exemplo, alguns pacotes têm licenças que proíbem a distribuição comercial. Outros podem ser distribuídos mas são de facto shareware e não software livre. As licenças de cada um destes pacotes têm de ser analisadas, e possivelmente negociadas, antes dos pacotes serem incluídos em qualquer meio de distribuição (ex, num CD-ROM).

  • stable/contrib/: Este directório contêm pacotes que são DFSG-free e eles próprios distribuíveis livremente, mas de qualquer modo dependem de um pacote que não é distribuível livremente e assim está apenas disponível na secção non-free.

6.5. O que é que a distribuição testing contém?

Os pacotes são instalados no directório `testing' após terem passado algum grau de teste em unstable.

Têm de estar em sincronismo com todas as arquitecturas para onde foram compilados e não podem ter dependências que os tornem não-instaláveis; também precisam ter ter menos bugs críticos-de-lançamento que as versões actualmente em unstable. Deste modo, nós esperamos que a 'testing' esteja sempre perto de ser candidata a lançamento.

Mais informação sobre o estado de "testing" em geral e dos pacotes individuais está disponível em https://www.debian.org/devel/testing.

6.5.1. Então e a "testing"? Como é 'congelada'?

Quando a distribuição "testing" está suficiente madura, o gestor de lançamentos começa a 'congela-la'. Os atrasos de propagação normais são aumentados para assegurar que mínimo possível de bugs de "unstable" entrem em "testing".

Após algum tempo, a distribuição "testing" fica verdadeiramente 'congelada''. Isto significa que todos os novos pacotes que estão para ser propagados para "testing" são impedidos, a menos que incluam correções para bugs críticos-de-lançamento. A distribuição "testing" também pode permanecer em tal profunda congelação durante os chamados 'ciclos-de-teste', quando o lançamento está eminente.

Quando um lançamento "testing" se torna 'congelado', "unstable" tende a parcialmente congelar também. Isto porque os desenvolvedores ficam relutantes em enviar software radicalmente novo para unstable, no caso do software congelado em testing precisar de actualizações menores e para corrigir bugs críticos de lançamento que impedem a testing de se tornar "stable".

Nós mantemos um registo dos bugs na distribuição "testing" que podem travar um pacote de ser lançado, ou bugs que podem travar o lançamento inteiro. Para detalhes, por favor veja informação de lançamento de testing actual.

Assim que essa contagem de bugs desce para valores máximos aceitáveis, a distribuição "testing" congelada é declarada "stable" e lançada com um número de versão.

A contagem de bugs mais importante é a contagem "Release Critical", a qual pode ser seguida em Página de estado de bugs críticos-de-lançamento. Um objectivo comum de lançamento é NoRCBugs o que significa que a distribuição não deve ter nenhuns bugs de severidade crítica, grave ou séria. A lista completa de problemas considerados críticos pode ser encontrada em Documento de política RC.

Com cada novo lançamento, a distribuição "stable" anterior torna-se obsoleta e é movida para o arquivo. Para mais informação por favor veja Arquivo Debian.

6.6. O que é que a distribuição unstable contém?

O directório `unstable' contém um instantâneo do actual sistema em desenvolvimento. Os utilizadores são bem vindos a usarem e testarem estes pacotes. mas são avisados sobre o seu estado de prontidão. A vantagem de usar a distribuição unstable é que você está sempre actualizado com o mais recente da indústria de software de GNU/Linux, mas se quebrar você fica com ambas as partes :-)

Existem também os sub-directórios main, contrib e non-free em `unstable', separados no mesmo critério como em `stable'.

6.7. O que são todos aqueles directórios nos arquivos Debian?

O software que foi empacotado para Debian GNU/Linux está disponível em uma das várias árvores de directórios em cada site de mirror Debian.

O directório dists é uma abreviatura para "distribuições", e é o modo canónico de aceder aos lançamentos de Debian actualmente disponíveis (e aos pré-lançamentos).

O directório pool contém os pacotes reais, veja Secção 6.10, “O que é o directório pool?”.

Estes são os seguintes directórios suplementares:

/tools/:

Utilitários de DOS para criar discos de arranque, particionar o seu disco rijo, comprimir/descomprimir ficheiros, e arrancar o Linux.

/doc/:

A documentação básica de Debian, tal como esta FAQ, as instruções do sistema de reporte de bugs, etc.

/indices/:

vários indices do site (o ficheiro Maintainers e os ficheiros de sobreposição).

/project/:

na maioria materiais apenas para desenvolvedores, e alguns ficheiros de conteúdos variados.

6.8. O que são esses directórios dentro de dists/stable/main?

Dentro cada uma das árvores de directórios maiores [3], existe três conjuntos de sub-directórios que contêm ficheiros de índice.

Existe um conjunto de sub-directórios binary-qualquer coisa que contêm ficheiros índice para pacotes binários de cada arquitectura de computador disponível, por exemplo binary-i386 para pacotes que executam em máquinas PC Intel x86 ou binary-sparc para pacotes que executam em Sun SPARCStations.

A lista completa de arquitecturas disponíveis para cada lançamento está disponível em a página web dos lançamentos. Para o lançamento actual, por favor veja Secção 4.1, “Em quais arquitecturas/sistemas de hardware Debian GNU/Linux corre?”.

Os ficheiro de índice em binary-* são chamados Packages(.gz, .bz2) e eles incluem um sumário de cada pacote binário que é incluído nessa distribuição. Os pacotes binários reais residem no directório pool de nível de topo.

Mais ainda, existe um sub-directório chamado source/ que contém ficheiros de índice para pacotes fonte incluídos na distribuição.. O ficheiro de índice é chamado Sources(.gz, .bz2).

Por último mas não menos importante, existe um conjunto de sub-directórios destinados aos ficheiros de índice do sistema de instalação, eles estão em debian-installer/binary-arquitectura.

6.9. Onde está o código fonte?

É incluído código fonte para tudo num sistema Debian. Mais ainda, os termos de licença da maioria dos programas no sistema requerem que o código fonte seja distribuído juntamente com os programas, ou uma oferta para fornecer o código fonte a acompanhar os programas.

O código fonte é distribuído no directório pool (veja Secção 6.10, “O que é o directório pool?”) juntamente com todos os directórios de binários específicos da arquitectura. Para obter o código fonte sem sem ter que estar familiarizado com a estrutura do arquivo, tente um comando como apt-get source nome-do-pacote.

Devido a restrições nas suas licenças, o código fonte pode ou pode não estar disponível para pacotes nas áreas "contrib" e "non-free", as quais não são partes formais do sistema Debian. Em alguns casos apenas podem ser distribuídos "bolhas binários" sem fonte (veja por exemplo firmware-misc-nonfree); em outros casos a licença proíbe a distribuição de binários pré-compilados, mas permite pacotes de código fonte que os utilizadores podem compilar localmente (veja broadcom-sta-dkms).

6.10. O que é o directório pool?

Os pacotes são mantidos numa grande `pool', estruturada de acordo com o nome do pacote fonte. Para tornar isto gerível, a pool é sub-dividida por secção (`main', `contrib' e `non-free') e pela primeira letra do nome do pacote fonte. Estes directórios contêm vários ficheiros: os pacotes binários para cada arquitectura, e os pacotes fonte de onde os pacotes binários foram gerados.

Você pode encontrar onde cada pacote está colocado ao executar um comando como apt-cache showsrc nome-do-pacote e olhar para a linha `Directory:'. Por exemplo, os pacotes apache estão armazenados em pool/main/a/apache/.

Adicionalmente, como existem tantos pacotes lib*, estes são tratados de modo especial: por exemplo, os pacotes libpaper são guardados em pool/main/libp/libpaper/.

[4]

6.11. O que é "incoming"?

Após um desenvolvedor enviar um pacote, este fica durante um curto espaço de tempo no directório "incoming" antes de ser verificado de que é genuíno e é permitido entrar no arquivo.

Normalmente ninguém deve instalar coisas deste local. No entanto, em casos raros de emergência, o directório incoming está disponível em https://incoming.debian.org/. Você pode obter os pacotes manualmente, verificar a assinatura GPG e MD5sums nos ficheiros .changes e .dsc, e depois instala-los.

6.12. Como é que Eu configuro o meu próprio repositório apropriado ao apt?

Se você compilou alguns pacotes Debian privados que gostaria de instala-los usando as ferramentas standard de gestão de pacotes Debian, você pode configurar o seu próprio arquivo de pacotes apt-compatível. Isto também é útil se desejar partilhar os seus pacotes Debian enquanto estes não são distribuídos pelo projeto Debian. Instruções de como fazer isto são dadas em Debian Wiki.



[2] Quando a sid do presente não existia, a organização dos sites FTP tinha uma falha grave: assumia-se que quando uma arquitectura é criada na unstable actual, iria ser lançada quando essa distribuição se tornasse a nova stable. Para muitas arquitecturas isso não é o caso, com o resultado que esses directórios tinham de ser movidos na data do lançamento. Isto era impraticável porque esse movimento comia imensa largura de banda.

Os administradores de arquivo contornaram este problema durante vários anos ao colocar os binários para arquitecturas não lançadas num directório especial chamado "sid". Para essas arquitecturas ainda não lançadas, na primeira vez que foram lançadas existiu um link da stable actual para sid, e a partir daí elas foram criadas dentro da árvore unstable como normal. Esta disposição foi um pouco confusa para os utilizadores.

Com o advento de pools de pacotes (veja Secção 6.10, “O que é o directório pool?”), os pacotes binários começaram a ser armazenados numa localização canónica na pool, independentemente da distribuição, assim lançar uma distribuição já não causava grandes consumos de largura de banda nos servidores espelho (existe, no entanto, muito consumo de largura de banda gradual durante o processo de desenvolvimento).

[3] dists/stable/main, dists/stable/contrib, dists/stable/non-free, e dists/unstable/main/, etc.

[4] Historicamente, os pacotes eram mantidos no sub-directório de dists correspondente a qual distribuição os continham. Isto tornou-se a causa de vários problemas, tal como grande consumo de largura de banda nos mirrors quando se faziam grandes alterações. Isto foi corrigido com a introdução da pool de pacotes.

Os directórios dists ainda são usados para os ficheiros de índice usados por programas como o apt.