Debians uttestningsutgåva

För grundläggande information om uttestningsutgåvan riktad till användare, se Debians frågor och svar.

Det är viktigt för både vanliga användare och utvecklare av uttestningsutgåvan att notera att säkerhetsuppdateringar för uttestningsutgåvan inte hanteras av säkerhetsgruppen. För ytterligare information, se säkerhetsgruppens frågor och svar.

Denna sida täcker huvudsakligen aspekter hos uttestningsutgåvan som är viktiga för Debianutvecklare.

Hur uttestningsutgåvan fungerar

Uttestningsutgåvan (testing) genereras automatiskt. Den skapas från den instabila utgåvan via ett antal skript vilka försöker flytta över paket som det är rimligt att anta att de saknar utgivningskritiska fel. Detta görs på ett sätt som ser till att beroenden hos andra paket alltid uppfyllda.

Ett paket (i en given version) kommer att flyttas över till uttestningsutgåvan när det uppfyller samtliga följande kriterier:

  1. Det måste ha funnits i den instabila utgåvan under minst 10, 5 eller 2 dagar, beroende på hur brådskande det insända paketet var;
  2. Den måste ha kompilerats och àjourförts för samtliga arkitekturer det tidigare har kompilerats för i den instabila utgåvan;
  3. Den får inte ha släppkritiska fel som inte redan finns i den nuvarande versionen i uttestningsutgåvan (se nedan för ytterligare information);
  4. Alla dess beroenden måste antingen uppfyllas av paket som redan finns i uttestningsutgåvan, eller uppfyllas av den grupp paket som skulle installeras samtidigt;
  5. Steget att installera paketet i uttestningsutgåvan får inte resultera i att andra paket som redan finns där slutar fungera. (Se nedan för ytterligare information.)

Ett paket som uppfyller de tre första punkterna ovan kallas en Valid Candidate (giltig kandidat).

Uppdateringsskripten visar när varje enskilt paket kan flyttas över från den instabila utgåvan till uttestningsutgåvan. Dess utdata består av två delar:

Ofta ställda/besvarade frågor

Vad är utgivningskritiska fel, och hur räknas de?

Alla fel som har en högre allvarlighetsgrad anses vara utgivningskritiskt (release-critical). För närvarande gäller detta graderna critical (kritiskt), grave (gravt) och serious (allvarligt).

Sådana fel anses ha betydelse för huruvida paketet kan ges ut i en stabil utgåva av Debian: normalt sett kommer inte ett paket som har öppna kritiska fel mot sig komma in i uttestningsutgåvan, och som en följd därav kommer det inte heller in i den stabila utgåvan.

Antalet fel i testing är alla utgivningskritiska fel som är markerade att gälla paket/versions-kombinationer som är tillgängliga i testing för en utgiven arkitektur.

Hur kan installation av ett paket i uttestningsutgåvan få andra paket att sluta fungera?

Distributionsarkiven är så strukturerade att de endast kan hantera en version av ett paket, där paket definieras av sitt namn. Så när källkodspaketet acmefoo installeras i uttestningsutgåvan, tillsammans med dess binärpaket acme-foo-bin, acme-bar-bin, libacme-foo1 och libacme-foo-dev tas den gamla versionen bort.

Den gamla versionen av paketet kan dock ha erhållit ett paket med ett gammalt so-namn för ett paket, till exempel libacme-foo0. Om man tar bort det gamla acmefoo försvinner libacme-foo0, vilket gör att de paket som beror på det slutar att fungera.

Uppenbarligen påverkar detta huvudsakligen paket som erhåller en föränderlig uppsättning paket i olika versioner (vilket i sin tur huvudsakligen gäller bibliotek). Det kan dock även påverka paket med versionsberoenden som har deklarerats med operatorerna ==, <= eller <<.

När den uppsättning binärpaket som kommer från ett källkodspaket ändras på detta sätt måste alla paket som beror på de gamla binärerna uppdateras så att de istället beror på de nya binärerna. Eftersom de paket som berodde på det i uttestningsutgåvan kommer gå sönder om man installerar ett sådant källkodspaket till den måste det göras omsorgsfullt: alla paket som beror på det måste uppdateras och i sig vara redo att installeras så att de inte går sönder, och när allting är färdigt krävs vanligtvis manuellt ingripande av utgivningsansvarige eller en assistent.

Om du har problem med komplicerade paketgrupper av det här slaget, kontakta debian-devel eller debian-release för hjälp.

Jag förstår fortfarande inte! Skripten för uttestningsutgåvan säger att paketet är en giltig kandidat, men det har fortfarande inte kommit med.

Detta händer oftast när paketet, direkt eller indirekt, skulle få ett annat paket att sluta fungera.

Kom ihåg att tänka på ditt pakets beroenden. Säg att ditt paket beror på libtool, eller libltdlX. Ditt paket kommer inte in i uttestningsutgåvan förrän rätt version av libtool är redo att komma in.

Detta i sin tur kommer inte att ske förrän installationen av libtool kan ske utan att andra saker i uttestningsutgåvan går sönder. Med andra ord, tills alla paket som beror på libltdlY (där Y är en tidigare version) har kompilerats om och deras kritiska fel har försvunnit, osv, kommer inget av dessa paket att kommer med i uttestningsutgåvan.

Det är här textutdatat [gzippat] är användbart: de ger tips (om än korthuggna) om vilka paket som kommer sluta fungera om en giltig kandidat kommer in i uttestningsutgåvan. (Se Utvecklarreferensen för mer information).

Varför är det ibland svårt att få paket med Architecture: all in i uttestningsutgåvan?

Om Architecture: all-paketet ska kunna installeras måste det vara möjligt att uppfylla dess beroenden på samtliga arkitekturer. Om den beror på ett specifikt paket som bara kompilerar på en delmängd av Debians arkitekturer kan inte så ske.

Uttestningsutgåvan kommer dock för närvarande att ignorera Architecture: all vad gäller pakets installerbarhet på icke-i386-arkitekturer. (Det är ett fult hack och jag är inte stolt över att ha utfört det, men... –aj)

Mitt paket fördröjs eftersom det inte är à jour för en viss arkitektur. Vad kan jag göra?

Kontrollera status för ditt paket i databasen över byggloggar. Om paketet inte kan byggas kommer det att markeras som failed (misslyckat); undersök byggloggarna och rätta de eventuella problem som orsakas av ditt pakets källkod.

Om du upptäcker att vissa arkitekturer har byggt den nya versionen av ditt paket men att de inte visas i utdatat från skripten för uttestningsutgåvan behöver du bara ha lite tålamod till dess att respektive buildd-ansvariga sänder in filerna till Debianarkivet.

Om du upptäcker att vissa arkitekturer inte har byggt den nya versionen av ditt paket över huvud taget, trots att du sände in en rättelse för ett tidigare fel är orsaken troligen att det markerats såsom väntande på beroenden (Dep-Wait). Du kan även se listan över de så kallade wanna-build-tillstånden för att försäkra dig om det.

Dessa problem rättas för det mesta till slut, men om du väntat under en längre tidsperiod (typ två veckor eller mer), påpeka det för respektive anpassnings buildd-ansvarige om en sådan adress finns angiven på anpassningens webbsida, eller till anpassningens sändlista.

Om du explicit har uteslutit arkitekturen från Architecture-litsan i control-filen och paketet tidigare har byggts för den arkitekturen måste du be om att det gamla binärpaketet tas bort från arkivet innan ditt paket kan komma in i uttestningsutgåvan. Du måste sända in en felrapport mot ”ftp.debian.org” och be om att den uteslutna arkitekturens paket skall tas bort den instabila utgåvan. Generellt sett bör även den relevanta anpassningens sändlista informeras av artighetsskäl.

Finns det undantag? Jag är säker på att acmefoo just kom in i uttestningsutgåvan utan att det uppfyller alla kraven.

Den ansvarige för utgåvorna kan åsidosätta reglerna på två sätt:

Kan du ge ett riktigt, icke-trivialt exempel?

Här är ett: när källkodspaketet apache installeras i uttestningsutgåvan tillsammans med sina binärpaket apache, apache-common, apache-dev och apache-doc tas den gamla versionen bort.

Alla Apachemoduler beror dock på apache-common (>= något), apache-common (<< något), så denna ändring förstör för samtliga dessa beroenden. Därför måste samtliga Apachemoduler kompileras om mot den nya versionen av Apache för att uttestningsutgåvan ska uppdateras.

Låt oss gå in på lite mer detaljer om detta: när alla moduler har uppdateras i den instabila utgåvan så att de fungerar med Apache prövar uttestningsskripten apache-common och upptäcker att det förstör alla Apachemoduler eftersom de har Depends: apache-common (<< nuvarande version), och prövar sedan libapache-foo för att få reda på att den inte kan installeras eftersom den har Depends: apache-common (>= den nya versionen).

Senare kommer de dock att använda en annan sorts logik (ibland på grund av manuellt ingripande): de kommer att ignorera det faktum att apache-common förstör saker och fortsätta med det som fungerar; om det fortfarande inte fungerar när vi gjort vad vi kan, så synd, men det kanske kommer att fungera. Senare kommer alla slumpmässiga libapache-foo-paket att prövas och skripten ser att de faktiskt fungerar.

När allt har prövats kontrolleras hur många paket har förstörts, beräknas om det är bättre eller sämre än hur det var tidigare och antingen accepteras allt eller så struntas det i. Du ser detta i update_output.txt på raderna med recur:.

Till exempel: 

     	  recur: [foo bar] baz

betyder i grund och botten att efter att redan ha upptäckt att foo och bar gör situationen bättre prövar jag nu baz för att se vad som händer, även om det får saker att sluta fungera. Raderna i update_output.txt som börjar med accepted indikerar att situationen verkar bli bättre, och skipped-rader gör situationen värre.

update_output.txt-filen är helt oläslig!

Det är inte en fråga. ;-)

Låt oss ta ett exempel:

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

Detta betyder att om cln tas med i uttestningsutgåvan kommer ginac-cint och libginac-dev inte att kunna installeras på i386 i uttestningsutgåvan. Observera att arkitekturerna kontrolleras i bokstavsordning och att bara problem för den första arkitekturen med problem visas – det är därför Alphaproblem förekommer så ofta.

Raden som börjar på got innehåller antalet problem i uttestningsutgåvan för de olika arkitekturerna (fram till den första arkitekturen där ett fel upptäcktes – se ovan). i-45 betyder att om cln tas in i uttestningsutgåvan skulle det finnas 45 oinstallerbara paket på i386. Några av posterna ovanför och nedanför cln visar att det fanns 43 oinstallerbara paket i uttestningsutgåvan för i386 vid den tidpunkten.

Raden skipped: cln (0) (150+4) betyder att det fortfarande finns 150 paket att gå genom efter detta paket innan denna kontroll av samtliga paket är färdig, och att fyra paket redan hittats som skripten inte planerar att uppgradera eftersom de skulle förstöra beroenden. (0) är irrelevant, så den kan du lugnt strunta i.

Observera att alla paket testas flera gånger när uttestningsskripten körs.

Jules Bean samlade ursprungligen de ofta ställa frågorna och svaren.

Ytterligare information

Följande sidor innehåller ytterligare information om det aktuella tillståndet för uttestningsutgåvan och hur paket förflyttas från den instabila utgåvn och dit:

Det kan vara intressant att läsa ett äldre förklarande e-brev. Dess enda stora fel är att den inte tar paketpoolerna i beaktning, då dessa implementerades av James Troup efter att brevet skrevs.

Koden för uttestningsutgåvan kan hämtas från ftp-master.

Anthony Towns får äran för att ha implementerat uttestningsutgåvan.