Inhoudsopgave
dists/stable/main
?pool
?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.
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"?”).
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.
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.
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 :-)
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.
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.
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.
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'.
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:
DOS-hulprogramma's voor het aanmaken van opstartdisks, voor schijfindeling, voor het comprimeren/decomprimeren van bestanden en om Linux op te starten.
De basale documentatie van Debian, zoals deze FAQ, de instructies voor het brugrapporteringssysteem, enz.
verschillende indexbestanden van de site (het bestand Maintainers en de override-bestanden).
voor het merendeel materiaal dat enkel voor ontwikkelaars bestemd is en enkele varia-bestanden.
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-
die indexbestanden
bevatten over binaire pakketten voor elke beschikbare
computerarchitectuur. Bijvoorbeeldiets
binary-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
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
).
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/
.
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.
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
.