Hoofdstuk 6. De FTP-archieven van Debian

Inhoudsopgave

6.1. Hoeveel distributies van Debian zijn er?
6.2. Wat beteken het soort namen zoals etch, lenny, enz.?
6.2.1. Welke ander codenamen werden in het verleden gebruikt?
6.2.2. Waar komen deze codenamen vandaan?
6.3. Hoe zit het met "sid"?
6.4. Wat bevat de map 'stable'?
6.5. Wat bevat de distributie 'testing'?
6.5.1. Hoe zit het met "testing"? Hoe wordt het 'bevroren'?
6.6. Wat zit er in de distributie unstable?
6.7. Wat betekenen al die mappen in de FTP-archieven van Debian?
6.8. Wat betekenen al deze mappen binnenin dists/stable/main?
6.9. Waar zit de broncode?
6.10. Wat is de map pool?
6.11. Wat is "incoming"?
6.12. Hoe zet ik mijn eigen pakketbron op die met apt gebruikt kan worden?

6.1. Hoeveel distributies van Debian zijn er?

Er bestaan drie hoofd-distributies: de stabiele distributie "stable", de test-distributie "testing" en de onstabiele distributie "unstable". Soms wordt de distributie "testing" 'bevroren' (zie Paragraaf 6.5.1, “Hoe zit het met "testing"? Hoe wordt het 'bevroren'?”). Daarnaast zijn er ook de oude stabiele distributie "oldstable" en de experimentele distributie "experimental".

"Experimental" wordt gebruikt voor pakketten die nog in ontwikkeling zijn en die een hoog risico in zich dragen om uw systeem onbruikbaar te maken. De distributie wordt gebruikt door ontwikkelaars die de allernieuwste software willen bestuderen en testen. Gebruikers moeten er geen pakketten van gebruiken, omdat ze zelfs voor de meest ervaren mensen gevaarlijk en schadelijk kunnen zijn.

Zie Hoofdstuk 3, Een Debian-distributie kiezen voor hulp bij het kiezen van een Debian-distributie.

6.2. Wat beteken het soort namen zoals etch, lenny, enz.?

Het zijn gewoon "codenamen". Wanneer een distributie van Debian zich in de ontwikkelingsfase bevindt, heeft ze geen versienummer, maar een codenaam. Het doel van die codenamen is het vergemakkelijken van het onderhoud van een spiegelserver voor de distributies van Debian (indien een echte map zoals unstable plots de naam stable zou krijgen zou dit het nodeloos opnieuw downloaden van een heleboel zaken tot gevolg hebben).

Momenteel is stable een symbolische koppeling met buster (d.w.z. Debian GNU/Linux 10) en testing een symbolische koppeling met bullseye. Dit betekent dat buster de huidige stabiele distributie is en bullseye de huidige test-distributie.

unstable is een permanente symbolische koppeling met sid, vermist sid steeds de onstabiele distributie blijft (zie Paragraaf 6.3, “Hoe zit het met "sid"?”).

6.2.1. Welke ander codenamen werden in het verleden gebruikt?

Naast buster en bullseye zijn andere codenamen die reeds gebruikt werden: buzz voor release 1.1, rex voor release 1.2, bo voor de releases 1.3.x, hamm voor release 2.0, slink voor release 2.1, potato voor release 2.2, woody voor release 3.0, sarge voor release 3.1, etch voor release 4.0, lenny voor release 5.0, squeeze voor release 6.0, wheezy voor release 7, jessie voor release 8, stretch voor release 9.

6.2.2. Waar komen deze codenamen vandaan?

Tot nu toe zijn het figuurtjes geweest uit de "Toy Story"-filmen van Pixar.

  • buzz (Debian 1.1) was the spaceman Buzz Lightyear,

  • rex (Debian 1.2) was the tyrannosaurus,

  • bo (Debian 1.3) was Bo Peep, the girl who took care of the sheep,

  • hamm (Debian 2.0) was the piggy bank,

  • slink (Debian 2.1) was Slinky Dog, the toy dog,

  • potato (Debian 2.2) was, of course, Mr. Potato,

  • woody (Debian 3.0) was the cowboy,

  • sarge (Debian 3.1) was the sergeant of the Green Plastic Army Men,

  • etch (Debian 4.0) was the toy whiteboard (Etch-a-Sketch),

  • lenny (Debian 5.0) was the toy binoculars,

  • squeeze (Debian 6) was the name of the three-eyed aliens,

  • wheezy (Debian 7) was the rubber toy penguin with a red bow tie,

  • jessie (Debian 8) was the yodeling cowgirl,

  • stretch (Debian 9) was the rubber toy octopus with suckers on her eight long arms.

  • buster (Debian 10) was Andy's pet dog.

  • bullseye (Debian 11) was Woody's wooden toyhorse.

  • bookworm (Debian 12) was a green toy worm with a built-in flashlight who loves reading books.

  • sid is het boosaaardige buurjongetje van naast de deur die al het speelgoed vernielt.

De keuze om namen uit Toy Story te gebruiken werd gemaakt door Bruce Perens die toen de Projectleider van Debian was en die ook bij Pixar werkte, het bedrijf dat de films produceerde.

6.3. Hoe zit het met "sid"?

sid of unstable is de plaats waar de meeste pakketten initieel geüpload worden. Deze distributie zal nooit rechtstreeks uitgebracht worden, aangezien pakketten die uitgebracht zullen worden eerst opgenomen moeten worden in testing om dan later in stable uitgebracht te worden. sid bevat pakketten voor zowel uitgebrachte als niet-uitgebrachte architecturen.

Ook de naam "sid" is afkomstig uit de tekenfilm "Toy Story": Sid is de buurjongen die speelgoed vernielt :-)

[2]

6.4. Wat bevat de map 'stable'?

  • stable/main/: deze map bevat de pakketten die formeel de meest recente release van het Debian GNU/Linux-systeem vormen.

    Al deze pakketten beantwoorden aan de Debian Free Software Guidelines en kunnen alle vrij gebruikt en verspreid worden.

  • stable/non-free/: deze map bevat pakketten waarvan de distributie aan restricties onderhevig is, zodat distributeurs de vermelde copyright-vereisten zorgvuldig in acht moeten nemen.

    Bijvoorbeeld hebben sommige pakketten een licentie die commerciële distributie verbiedt. Andere mogen verspreid worden, maar zijn in feite shareware en geen vrije software. De licentie van elk van deze pakketten moet bestudeerd worden en eventueel heronderhandeld alvorens deze pakketten opgenomen worden op een distributiemedium (bijvoorbeeld een CD).

  • stable/contrib/: deze map bevat pakketten die zelf vrij zijn volgens de DFSG en vrij verspreid mogen worden, maar die op een of andere manier een pakket vereisen dat niet vrij verspreid mag worden en dus enkel in de sectie non-free te vinden is.

6.5. Wat bevat de distributie 'testing'?

Pakketten worden in de map 'testing' geïnstalleerd nadat ze in zekere mate getest werden in unstable.

Op alle architecturen waarop ze gebouwd werden, moeten ze onderling synchroon zijn en ze mogen geen vereisten hebben die tot gevolg hebben dat ze niet geïnstalleerd kunnen worden. Ze moeten ook minder bugs hebben die in functie van de release cruciaal zijn, dan de versie die momenteel in 'unstable' zit. We hopen dat op die manier 'testing' steeds dicht de toestand van release-kandidaat benadert.

Meer informatie over de status van "testing" in het algemeen en over de individuele pakketten is te vinden op https://www.debian.org/devel/testing.

6.5.1. Hoe zit het met "testing"? Hoe wordt het 'bevroren'?

Als de "testing"-distributie voldoende matuur is, begint de releasemanager het te 'bevriezen'. De normale doorschuifvertraging wordt verhoogd om te verzekeren dat zo weinig mogelijk nieuwe bugs vanuit "unstable" in "testing" binnenkomen.

Na een tijd wordt de "testing"-distributie echt 'bevroren'. Dit betekent dat alle nieuwe pakketten die naar "testing" zouden moeten doorschuiven, tegengehouden worden, tenzij zij reparaties bevatten van bugs die cruciaal zijn voor de release. De "testing"-distributie kan ook in een dergelijke diepe bevriezing blijven tijdens de zogenaamde 'test-cycli' wanneer de release ophanden is.

Wanneer een testing"-release 'bevroren' wordt, heeft ook "unstable" ten dele de neiging te bevriezen. Dit is omdat ontwikkelaars weigerachtig staan tegen het uploaden van radicaal nieuwe software in unstable, voor het geval de bevroren software in testing kleine updates nodig mocht hebben voor het repareren van voor de release cruciale bugs die verhinderen dat testing "stable" kan worden.

We houden een register bij van bugs in de "testing"-distributie die de release van een pakket kunnen tegenhouden en van bugs de de hele release kunnen tegenhouden. Raadpleeg voor meer informatie de release-informatie over de huidige testing-release.

Eens het aantal bugs lager ligt dan het maximaal aanvaardbare, wordt de bevroren "testing"-distributie stabiel verklaard en uitgegeven met een versienummer.

Het belangrijkste aantal bugs is dat van deze welke "cruciaal zijn voor de release" (de zogenaamde release critical bugs). Dit aantal kan gevolgd worden op de Statuspagina over release-critical bugs. Een algemeen erkende releasedoelstelling is NoRCBugs - geen release critical bugs, wat betekent dat de release geen bugs zou mogen bevatten die een graad van ernstigheid hebben van cruciaal, zorgwekkend of ernstig. De volledige lijst van zaken die als cruciaal beschouwd worden, is te vinden in het beleidsdocument inzake RC.

Bij elke nieuwe release wordt de vorige "stable" release als verouderd bestempeld en verhuist deze naar het archief. Raadpleeg voor bijkomende informatie Het Debian-archief.

6.6. Wat zit er in de distributie unstable?

De map 'unstable' bevat een momentopname van het huidige systeem in ontwikkeling. Gebruikers worden uitgenodigd om deze pakketten te gebruiken en uit te testen, maar worden gewaarschuwd wat hun staat van onafheid betreft. Het voordeel van het gebruik van de onstabiele distributie is dat u altijd up-to-date bent wat de meest recente software voor GNU/Linux betreft, maar als er iets fout gaat, dan zit u met de brokken :-)

Ook in 'unstable' bestaan de onderliggende mappen main, contrib en non-free, waarvoor dezelfde criteria gehanteerd worden als in 'stable'.

6.7. Wat betekenen al die mappen in de FTP-archieven van Debian?

De software die voor Debian GNU/Linux verpakt werd, is te vinden op elke Debian-spiegelserver in een van de verschillende mappenbomen.

De map dists is een afkorting van "distributies" en het is de geëigende manier om toegang te krijgen tot de huidige beschikbare releases (en pre-releases) van Debian.

De map pool bevat de eigenlijke pakketten. Zie Paragraaf 6.10, “Wat is de map pool?”.

Er zijn ook nog de volgende bijkomende mappen:

/tools/:

DOS-hulprogramma's voor het aanmaken van opstartdisks, voor schijfindeling, voor het comprimeren/decomprimeren van bestanden en om Linux op te starten.

/doc/:

De basale documentatie van Debian, zoals deze FAQ, de instructies voor het brugrapporteringssysteem, enz.

/indices/:

verschillende indexbestanden van de site (het bestand Maintainers en de override-bestanden).

/project/:

voor het merendeel materiaal dat enkel voor ontwikkelaars bestemd is en enkele varia-bestanden.

6.8. Wat betekenen al deze mappen binnenin dists/stable/main?

Within each of the major directory trees[3], there are three sets of subdirectories containing index files.

Er is een groep van onderliggende mappen binary-iets die indexbestanden bevatten over binaire pakketten voor elke beschikbare computerarchitectuur. Bijvoorbeeldbinary-i386 voor pakketten die werken op PC's van het type Intel x86 of binary-sparc voor pakketten die werken op Sun SPARCStations.

De volledige lijst van beschikbare architecturen voor elke release is te vinden op de webpagina van de release. Zie voor de huidige release Paragraaf 4.1, “Op welke hardwarearchitecturen/systemen kan Debian GNU/Linux werken?”.

De indexbestanden in binary-* heten Packages(.gz, .bz2) en ze bevatten een samenvatting van elk binair pakket dat tot die distributie behoort. De echte binaire pakketten bevinden zich in de basismap pool.

Voorts is er nog een onderliggende map source/ die indexbestanden bevat voor de bronpakketten die in de distributie zitten. Het indexbestand heet Sources(.gz, .bz2).

Tenslotte is er nog een groep onderliggende mappen die bedoeld zijn voor de indexbestanden van het installatiesysteem. Zij zitten in debian-installer/binary-architectuur.

6.9. Waar zit de broncode?

Van alles wat in het Debian-systeem aanwezig is, wordt de broncode opgenomen. Daarenboven vereisen de licentiebepalingen van de meeste programma's in het systeem dat de broncode samen met het programma meegeleverd wordt of dat bij het programma een aanbod voor het bezorgen van de broncode gevoegd wordt.

De broncode wordt verdeeld in de map pool (zie Paragraaf 6.10, “Wat is de map pool?”) samen met al de mappen met architectuur-specifieke binaire pakketten. Om de broncode op te halen zonder dat u vertrouwd moet zijn met de structuur van het FTP-archief, kunt u een commando zoals apt-get source pakketnaam gebruiken.

Wegens restricties in hun licentiebepalingen kan het zijn dat de broncode van pakketten die zich in de gebieden "contrib" en "non-free" bevinden en niet formeel deel uitmaken van het Debian-systeem, al dan niet beschikbaar is. In sommige gevallen mogen enkel zogenaamde "binary blobs" zonder broncode verdeeld worden (zie bijvoorbeeld firmware-misc-nonfree). In andere gevallen verbiedt de licentie het verdelen van vooraf gebouwde binaire bestanden, maar laat toe dat pakketten met broncode verdeeld worden die gebruikers lokaal kunnen compileren (zie broadcom-sta-dkms).

6.10. Wat is de map pool?

Pakketten worden in een grote 'pool' bijgehouden die gestructureerd is op basis van de naam van het bronpakket. Om dit beheersbaar te maken wordt de pool onderverdeeld volgens sectie ('main', 'contrib' en 'non-free') en volgens de eerste letter van de naam van het bronpakket. Deze mappen bevatten verschillende bestanden: de binaire pakketten voor elk van de architecturen en de bronpakketten waaruit de binaire pakketten gegenereerd werden.

U kunt de plaats van elk pakket te weten komen door een commando te gebruiken zoals apt-cache showsrc pakketnaam en dan te kijken naar de regel 'Directory:'. De apache-pakketten liggen opgeslagen in pool/main/a/apache/.

Daarbij komt nog dat lib*-pakketten op eeen bijzondere manier behandeld worden, omdat ze zo talrijk zijn. De libpaper-pakketten worden bijvoorbeeld opgeslagen in pool/main/libp/libpaper/.

[4]

6.11. Wat is "incoming"?

Nadat een ontwikkelaar een pakket geüpload heeft, blijft het voor een korte periode zitten in de map "incoming" waar nagegaan wordt of het authentiek is, voordat het toegelaten wordt in het archief.

Normaal zou niemand zaken uit die map moeten installeren. Voor die enkele zeldzame gevallen van hoogdringendheid evenwel, staat de map van binnenkomende pakketten (incoming) ter beschikking op https://incoming.debian.org/. U kunt handmatig pakketten ophalen, de GPG-ondertekening en de MD5sums controleren in de bestanden .changes en .dsc en ze dan installeren.

6.12. Hoe zet ik mijn eigen pakketbron op die met apt gebruikt kan worden?

Indien u zelf een aantal Debian-pakketten gebouwd heeft die u wenst te installeren met behulp van de standaardgereedschappen voor pakketbeheer van Debian, dan kunt u uw eigen pakketarchief dat met apt gebruikt kan worden, opzetten. Dit is ook handig als u uw Debian-pakketten wenst te delen terwijl ze niet door het Debian-project verdeeld worden. Instructie over hoe u dit moet doen worden gegeven op de Debian Wiki.



[2] When the present-day sid did not exist, the FTP site organization had one major flaw: there was an assumption that when an architecture is created in the current unstable, it will be released when that distribution becomes the new stable. For many architectures that isn't the case, with the result that those directories had to be moved at release time. This was impractical because the move would chew up lots of bandwidth.

The archive administrators worked around this problem for several years by placing binaries for unreleased architectures in a special directory called "sid". For those architectures not yet released, the first time they were released there was a link from the current stable to sid, and from then on they were created inside the unstable tree as normal. This layout was somewhat confusing to users.

With the advent of package pools (see Paragraaf 6.10, “Wat is de map pool?”), binary packages began to be stored in a canonical location in the pool, regardless of the distribution, so releasing a distribution no longer causes large bandwidth consumption on the mirrors (there is, however, a lot of gradual bandwidth consumption throughout the development process).

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

[4] Historically, packages were kept in the subdirectory of dists corresponding to which distribution contained them. This turned out to cause various problems, such as large bandwidth consumption on mirrors when major changes were made. This was fixed with the introduction of the package pool.

The dists directories are still used for the index files used by programs like apt.