De “testing”-distributie van Debian

Voor basale informatie voor de gebruiker over de testing-distributie moet u de Debian FAQ raadplegen.

Een belangrijke opmerking, zowel voor gewone gebruikers als voor de ontwikkelaars van testing, is dat beveiligingsupdates voor testing niet door het veiligheidsteam beheerd worden. Raadpleeg voor meer informatie de FAQ van het veiligheidsteam.

Op deze pagina worden hoofdzakelijk aspecten van testing behandeld die belangrijk zijn voor ontwikkelaars van Debian.

Hoe testing werkt

De testing-distributie is een automatisch gegenereerde distributie. Ze wordt gegenereerd vanuit de unstable-distributie door een aantal scripts welke pakketten die redelijk waarschijnlijk geen release-kritieke bugs bevatten, proberen over te plaatsen. Zij doen dit op zodanige wijze dat ervoor gezorgd wordt dat steeds voldaan kan worden aan de vereisten van andere pakketten in testing.

Een (specifieke versie van een) pakket zal naar testing doorschuiven wanneer het aan al de volgende criteria beantwoordt:

  1. Het moet aanwezig geweest zijn in unstable gedurende 10, 5 of 2 dagen, afhankelijk van de dringendheid van de upload;
  2. Het moet gecompileerd en up-to-date zijn voor alle architecturen waarvoor het vroeger in unstable gecompileerd geweest is;
  3. Het mag geen release-kritieke bugs bevatten die nog niet aanwezig zijn in de huidige versie in testing (zie hieronder voor meer informatie);
  4. Al zijn vereisten moeten ofwel beantwoord worden door reeds in testing aanwezige pakketten, of beantwoord kunnen worden door de groep pakketten die tegelijkertijd geïnstalleerd zullen worden;
  5. Het installeren van het pakket in testing mag geen enkel pakket dat momenteel in testing is, onklaar maken. (Zie hierna voor meer informatie.)

Een pakket dat aan de eerste drie bovenstaande vereisten beantwoordt, wordt een Geldige Kandidaat genoemd.

Het updatescript geeft weer wanneer welk pakket van unstable naar testing zou kunnen verhuizen. Het heeft een tweevoudige uitvoer:

Vaak gestelde/beantwoorde vragen

Wat zijn release-kritieke bugs en hoe worden ze geteld?

Alle bugs met een zekere graad van ernstigheid worden standaard beschouwd als release-kritiek; momenteel zijn dit bugs die gecatalogeerd worden als critical (kritiek), grave (ernstig) of serious (serieus).

Van dergelijke bugs wordt aangenomen dat ze een impact hebben op de kansen die het pakket heeft om uitgebracht te worden in de stabiele release van Debian: algemeen gesteld geldt dat als er tegen een pakket release-kritieke bugs gerapporteerd werden, het niet in testing zal geraken en bijgevolg niet uitgebracht zal worden in stable.

Onder het totaal aantal testing-bugs worden alle release-kritieke bugs verstaan die gelden voor in testing beschikbare pakket/versie-combinaties voor een release-architectuur.

Hoe kan het installeren van een pakket in testing mogelijk andere pakketten onklaar maken?

De structuur van de distributiearchieven is dusdanig dat deze slechts één versie van een pakket kunnen bevatten; een pakket wordt door zijn naam gedefinieerd. Indien dus het broncodepakket acmefoo in testing geïnstalleerd wordt, samen met zijn binaire pakketten acme-foo-bin, acme-bar-bin, libacme-foo1 en libacme-foo-dev, wordt de oude versie verwijderd.

De oude versie kan echter een binair pakket leveren met een bibliotheek met oude soname, zoals libacme-foo0. Het verwijderen van het oude acmefoo zal het verwijderen van libacme-foo0 met zich meebrengen, wat eventuele pakketten die ervan afhankelijk zijn, onklaar zal maken.

Het is duidelijk dat dit vooral pakketten betreft die een wijzigend geheel van binaire pakketten aanbieden in een volgende versie (nogmaals, hoofdzakelijk bibliotheken). Het zal echter ook pakketten betreffen waarover andere pakketten hebben aangegeven dat ze een specifieke versie ervan vereisen, in de vorm van ==, <= of <<.

Wanneer het geheel van binaire pakketten dat een broncodepakket levert, op die manier verandert, zullen alle pakketten die afhankelijk waren van de oude binaire pakketten, moeten opgewaardeerd worden om de nieuwe binaire pakketten te gaan vereisen. Omdat de installatie in testing van een dergelijk broncodepakket alle pakketten in testing onklaar maakt die er afhankelijk van zijn, moeten er enige voorzorgen getroffen worden: alle afhankelijke pakketten moeten zelf ook opgewaardeerd worden en klaar zijn voor installatie, zodat ze niet onklaar gemaakt zullen worden, en eens alles klaar is, is normaal een handmatige interventie vereist van de releasemanager of een assistent.

Indien u problemen ervaart met dergelijke gecompliceerde groepen pakketten, contacteert u best debian-devel of debian-release voor hulp.

Ik versta het nog steeds niet! De testing-scripts zeggen dat dit pakket een geldige kandidaat is, maar het is nog steeds niet in testing geraakt.

Dit gebeurt meestal wanneer het installeren van het pakket op een of andere manier, rechtstreeks of onrechtstreeks, een ander pakket onklaar zou maken.

Denk eraan om de vereisten van uw pakket na te gaan. Veronderstel dat uw pakket libtool of libltdlX vereist. Uw pakket zal dan testing niet binnengaan zolang de juiste versie van libtool niet klaar is om er samen mee naartoe te gaan.

Op zijn beurt zal dit niet gebeuren totdat het installeren van libtool geen zaken onklaar maakt die reeds aanwezig zijn in testing. Met andere woorden, totdat alle andere pakketten die libltdlY vereisen (waarbij Y de vorige versie is), opnieuw gecompileerd werden en al hun release-kritieke bugs weggewerkt zijn, enz., zal geen enkel van deze pakketten in testing belanden.

Dit is waar de tekstuele uitvoer [met gzip gecomprimeerd] van pas komt: deze geeft aanwijzingen (zij het zeer beknopte) over welke pakketten onklaar raken wanneer een geldige kandidaat aan testing toegevoegd wordt (zie het Referentiehandboek voor ontwikkelaars voor meer details).

Waarom is het soms moeilijk om pakketten van het type Architecture: all in testing te krijgen?

Indien het pakket van het type Architecture: all geïnstalleerd moet worden, moet het mogelijk zijn om te voldoen aan al zijn vereisten op alle architecturen. Als het bepaalde pakketten vereist die enkel gecompileerd kunnen worden op een beperkt aantal architecturen die Debian ondersteunt, lukt dat niet.

Voorlopig evenwel zal testing geen rekening houden met de installeerbaarheid van pakketten van het type Architecture: all op niet-i386 architecturen. (Het is een grove ingreep en ik ben er niet erg gelukkig mee dat ik hem gedaan heb, maar hier gaan we dan. —aj)

Mijn pakket werd geblokkeerd omdat het verouderd is op sommige architecturen. Wat moet ik doen?

Kijk de toestand van uw pakket na in de databank met compilatielogs. Indien het pakket niet gecompileerd raakt, zal het gemarkeerd staan als failed; onderzoek de compilatielogs en repareer eventuele problemen die veroorzaakt worden door de broncode van uw pakket.

Indien u merkt dat de nieuwe versie van uw pakket op sommige architecturen gecompileerd werd, maar dat het nog niet opduikt in de uitvoer van de testing-scripts, moet u gewoon een beetje meer geduld hebben tot de desbetreffende buildd-verantwoordelijke de bestanden naar het Debian archief uploadt.

Indien u merkt dat de nieuwe versie van uw pakket op sommige architecturen helemaal niet gecompileerd raakt, ondanks het feit dat u een reparatie uploadde voor een eerdere mislukking, is de reden wellicht dat het gemarkeerd staat als aan het wachten op vereisten (Dep-Wait). U kunt ook de lijst bekijken van deze zogenaamde wanna-build states om zich ervan te vergewissen.

Gewoonlijk raken deze problemen uiteindelijk opgelost, maar indien u reeds gedurende een lange periode aan het wachten bent (laat ons zeggen twee weken of langer), verwittig dan de desbetreffende buildd-verantwoordelijke voor die architectuur, mocht u daarvan een adres kunnen terugvinden op de webpagina over ports/architecturen, of licht de mailinglijst voor die architectuur in.

Indien u in het control-bestand een architectuur expliciet weggelaten heeft uit de lijst 'Architecture', maar dat pakket vroeger wel gecompileerd werd voor deze architectuur, zult u moeten vragen dat het oude binaire pakket voor deze architectuur verwijderd wordt uit het archief, vooraleer uw pakket naar testing kan overgaan. U moet een bugrapport opmaken tegen ftp.debian.org met de vraag om het pakket voor de architectuur die niet langer ondersteund wordt, te verwijderen uit het archief van unstable. Uit beleefdheid moet over het algemeen ook de mailinglijst van de desbetreffende architectuur/port geïnformeerd worden.

Zijn er uitzonderingen? Ik ben er zeker van dat acmefoo zonet toch in testing binnengekomen is, ondanks het feit dat het niet aan alle vereisten beantwoordde.

De releasemanagers kunnen de regels op twee manieren omzeilen:

Kunt u een reëel, niet-onbelangrijk voorbeeld geven?

Hier volgt er een: wanneer het broncodepakket apache in testing wordt geïnstalleerd, samen met zijn binaire pakketten apache, apache-common, apache-dev en apache-doc, wordt de oude versie verwijderd.

Alle pakketten met Apache modules vereisen evenwel apache-common (>= iets), apache-common (<< iets), en dus maakt deze wijziging al deze afhankelijke pakketten onklaar. Als gevolg hiervan moeten alle Apache modules opnieuw gecompileerd worden tegen de nieuwe versie van Apache, zodat testing geüpdatet kan worden.

Laten we hier iets dieper op ingaan: nadat alle modules in unstable bijgewerkt werden om te werken met een nieuwe versie van Apache, onderzoeken de testing-scripts apache-common en stellen vast dat dit alle Apache-modules onklaar maakt, omdat die de volgende vereiste hebben: Depends: apache-common (<< de huidige versie). En daarna onderzoeken zij libapache-foo en stellen vast dat het niet geïnstalleerd wordt omdat het de vereiste Depends: apache-common (>= de nieuwe versie) heeft.

Later zullen zij evenwel een andere logica toepassen (soms ingegeven door een handmatige interventie): zij zullen het feit dat apache-common bepaalde zaken onklaar maakt, negeren en doorgaan met zaken die werken: als het nog steeds niet werkt nadat we alles gedaan hebben wat in onze mogelijkheden lag, dan is dat pech, maar misschien zal het toch wel werken. Later zullen ze alle willekeurige libapache-foo-pakketten onderzoeken en vaststellen dat deze inderdaad werken.

Nadat ze alles geprobeerd hebben, zullen ze nagaan hoeveel pakketten onklaar gemaakt werden, bepalen of dit beter of slechter is dan wat er origineel was, en zullen ze ofwel alles aanvaarden of de zaak maar laten zitten. U ziet dit in update_output.txt op de recur:-regels.

Bijvoorbeeld:

         recur: [foo bar] baz

In essentie zegt dit: ik heb reeds ontdekt dat foo en bar de zaken beter maken; nu probeer ik baz om te zien wat er gebeurt, ook al maakt dit zaken onklaar. De regels van update_output.txt die beginnen met accepted geven zaken aan die de dingen blijkbaar beter maken, en de regels met skipped, zaken die de dingen slechter maken.

Het bestand update_output.txt is totaal onleesbaar!

Dit is geen vraag. ;-)

Laten we een voorbeeld geven:

 skipped: cln (0) (150+4)
     got: 167+0: a-40:a-33:h-49:i-45
     * i386: ginac-cint, libginac-dev

Dit betekent dat indien cln testing binnen gaat, ginac-cint en libginac-dev oninstalleerbaar worden in testing op i386. Merk op dat de architecturen in alfabetische volgorde gecontroleerd worden en dat enkel de problemen op de eerste architectuur weergegeven worden — dat is de reden waarom de architectuur alpha zo vaak voorkomt.

De got-regel bevat het aantal problemen in testing op de verschillende architecturen (tot aan de eerste architectuur waarvoor een probleem aangetroffen wordt — zie hierboven). Het i-45 betekent dat indien cln testing zou binnengaan, er 45 oninstalleerbare pakketten zouden zijn op i386. Sommige van de gegevens boven en onder cln geven aan dat er op dat moment 43 oninstalleerbare pakketten waren in testing op i386.

De regel skipped: cln (0) (150+4) geeft aan dat er na dit pakket nog altijd 150 pakketten nagekeken moeten worden vooraleer deze controle van alle pakketten voltooid zal zijn, en dat reeds 4 pakketten aangetroffen werden waarvoor geen opwaardering gepland wordt, omdat zij afhankelijke pakketten onklaar zouden maken. De (0) is irrelevant en u kunt dit gewoon negeren.

Merk op dat er in één doorloop van een testing-script verschillende controles worden uitgevoerd op alle pakketten.

Oorspronkelijk werden de veel gestelde vragen en antwoorden samengesteld door Jules Bean.

Bijkomende informatie

De volgende pagina's verschaffen bijkomende informatie over de actuele toestand van testing en over de overgang van pakketten uit unstable naar testing:

Misschien interesseert het u om een oudere uitleg in een e-mail te lezen. Het enige belangrijke nadeel ervan is dat hij geen rekening houdt de pakket-pool, omdat deze door James Troup geïmplementeerd werd, nadat de e-mail al geschreven was.

De testing broncode is te vinden op ftp-master.

Anthony Towns heeft de implementatie van testing gerealiseerd.