Debians 'testing'-distribution

For at få generelle, brugerorienterede oplysninger om distributionen testing, se Debians OSS.

En vigtig ting at bemærke, både for almindelige brugere og udviklerne af testing, er at sikkerhedsopdateringer til testing ikke varetages af sikkerhedsteamet. For flere oplysninger, se sikkerhedsteamets OSS.

Denne side handler primært om ting vedrørende testing, der er vigtige for Debian-udviklere.

Hvordan testing fungerer

Testing-distributionen genereres automatisk. Den genereres ud fra distributionen unstable af nogle skripter som prøver at flytte pakker der indenfor rimelighedens grænser ikke forventes at indeholde udgivelseskritiske fejl. Det gøres på en måde, der sikrer at afhængigheder med andre pakker i testing altid er opfyldt.

En (given version af en) pakke bliver flyttet til testing når den opfylder samtlige følgende kriterier:

  1. Den skal have været i unstable i 10, 5 eller 2 dage, afhængigt af hvor meget upload af pakken hastede;
  2. Den skal være oversat og ajourført på alle arkitekturer som den tidligere har været oversat til i unstable;
  3. Den skal have udgivelseskritiske fejl, som ikke også gælder versionen i testing (se neden for for flere oplysninger);
  4. Alle dens afhængigheder skal enten kunne opfyldes af pakker som allerede er i testing, eller skal kunne opfyldes af en gruppe pakker som vil blive placeret deri på samme tid;
  5. Processen med at placere pakken i testing må ikke medføre at andre pakker i testing holder op med at virke. (Se nedenfor for flere oplysninger.)

En pakke som opfylder de første tre punkter ovenfor, kaldes en Valid Candidate.

Opdateringsskriptet viser hvornår enhver pakke kan tænkes at blive flyttet fra unstable til testing. Dets uddata er dobbelt:

Ofte stillede/besvarede spørgsmål

Hvad er udgivelseskritiske fejl og hvordan optæller man dem?

Alle fejl med en højere alvorlighedsgrad betragtes som standard, som udgivelseskritiske (release-critical); for tiden er det critical (kritisk), grave (graverende) og serious (alvorlig) fejl.

Sådanne fejl antages at have betydning for hvorvidt en pakke vil blive udgivet med den stabile udgave af Debian: generelt, hvis en pakke har åbne udgivelseskritiske fejl mod sig, kommer den ikke ind i testing, og dermed bliver den heller ikke udgivet i stable.

Optællingen af fejl i testing er alle udgivelseskritiske, der er angivet som gældende for package/version-kombinationer, som er tilgængelige i testing til en udgivet arkitektur.

Hvordan kan overførslen af en pakke til testing overhovedet få andre pakker til at holde op med at virke?

Strukturen på distributionsarkiverne er sådan, at de kun kan indeholde en version af en pakke; en pakke defineres via sit navn. Derfor, når kildekode-pakken acmefoo overføres til testing, sammen med sine binære pakker acme-foo-bin, acme-bar-bin, libacme-foo1 og libacme-foo-dev, fjernes den gamle version.

Dog kan den gamle version have leveret et gammelt soname på et bibliotek til en binær pakke, såsom libacme-foo0. Fjernes den gamle acmefoo fjernes libacme-foo0, hvilket resulterer i at alle pakker der er afhængig af den, holder op med at virke.

Dette påvirker hovedsagligt pakker der stiller foranderlige binære pakker i forskellige versioner til rådighed (dermed primært biblioteker). Dog vil det også påvirke pakker, hvortil der er knyttet versionsafhængigheder af typerne ==, <= or <<.

Når de binære pakker som leveres af en kildekodepakke ændrer sig på denne måde, skal alle pakker som er afhængige af de gamle binære filer ændres til at være afhængige af de nye binære filer i stedet for. Da installering af den sådan kildekodepakke i testing får alle pakker, som er afhængige af den, til at holde op med at virke, skal man være omhyggelig: Alle afhængige pakker skal opdaterede og parate til selv at blive installeret, så de fortsat vil virke og, når alt er parat, vil manuel indgriben af den udgivelsesansvarlige eller en assistent normalt være påkrævet.

Hvis du har problemer med komplicerede pakkegrupper som denne, så kontakt debian-devel eller debian-release for at få hjælp.

Jeg forstår det stadig ikke! testing-skripterne siger at denne pakke er en valid candidate, men den er stadig ikke overført til testing.

Dette har tilbøjelighed til at ske, når en installering, direkte eller indirekte, vil få andre pakker til at holde op med at virke.

Husk at overveje din pakkes afhængigheder. Lad os antage at din pakke er afhængig af libtool, eller libltdlX. Din pakke vil ikke blive overført til testing, før den rigtige version af libtool er parat til at følge med.

Det vil dermed ikke ske, før en installering af libtool ikke resultere i at ting, som allerede er i testing holder op med at virke. Med andre ord, indtil alle andre pakker som er afhængige af libltdlY (hvor Y er den tidligere version) er blevet genoversat, og alle deres udgivelseskritiske fejl er væk, osv., vil ingen af disse pakker bliver overført til testing.

Her er tekstuddataene [gzip'et] nyttige: de giver tips (omend meget kortfattede) til hvilke pakker som holder op med at virke, når en valid candidate overføres til testing (se Udviklernes reference for flere oplysninger).

Hvorfor er det nogle gange svært at få Architecture: all-pakker overført til testing?

Hvis Architecture: all-pakken skal overføres, skal det være muligt at opfylde alle dens afhængigheder på alle arkitekturer. Hvis den er afhængig af bestemte pakker som kun kan oversættes på et begrænset antal af Debians arkitekturer, så kan det ikke lade sig gøre.

Dog vil testing indtil videre ignorere Architecture: all-pakkers installérbarhed på ikke-i386-arkitekturer. (Det er en stort 'hack' og jeg er ikke stolt over at have gjort det, men... --aj)

Min pakke kommer ikke videre fordi den ikke er ajour for alle arkitekturer. Hvad gør jeg?

Kontroller din pakkes status i build-log-databasen. Hvis pakken ikke bliver oversat, vil den blive markeret som failed; undersøg build-logfilerne og ret de problemer som eventuelt er forsaget af din pakkes kildekode.

Hvis du tilfældigvis bemærker at den nye version af pakken er oversat til nogle arkitekturer, men ikke viser sig i testing-skripternes uddata, er du nødt til at være lidt mere tålmodig indtil den ansvarlige buildd-vedligeholder overfører filerne til Debians arkiv.

Hvis du bemærker at nogle arkitekturer overhovedet ikke har oversat den nye version af pakken, på trods af at du har overført en rettelse til en tidligere fejl, er grunden formentlig at den er markeret som ventende på afhængigheder (Dep-Wait). Se også listen over disse såkaldte wanna-build-tilstande (states) for at blive helt sikker.

Disse problemer bliver som regel rettet med tiden, men hvis du har ventet i længere tid (lad os sige to uger eller mere), så giv den ansvarlige buildd-vedligeholder besked, hvis en sådan adresse er angivet på tilpasningswebsiden, eller tilpasningens postliste.

Hvis du eksplicit har fjernet en arkitektur fra Architecture-listen i kontrolfilen, og pakken tidligere er blevet opbygget for den arkitektur, skal du bede om at den gamle binære pakke til denne arkitektur bliver fjernet fra arkivet, før din pakke kan komme i testing-distributionen. Du skal indsende en fejl mod ftp.debian.org hvor du beder om fjernelse af arkitekturens pakker fra den ustabile distribution. Generelt bør man af almindelig høflighed orientere den relevante tilpasnings-postliste.

Er der nogen undtagelser? Jeg er sikker på at acmefoo lige er blevet overført til testing på trods af at alle krav ikke er opfyldt.

Udgivelsesadministratorene (release managers) kan tilsidesætte reglerne på to måder:

Har du et rigtigt, ikke-trivielt eksempel?

Her er et: når kildekode-pakken apache overføres til testing, sammen med sin binære pakker apache, apache-common, apache-dev og apache-doc, fjernes den gamle version.

Dog er alle modulpakker til Apache afhængige af apache-common (>= et-eller-andet), apache-common (<< et-eller-andet), så denne ændring ødelægger alle disse afhængigheder. Som følge deraf skal alle Apache-moduler oversættes mod den nye version af Apache for at testing kan opdateres.

Lad os uddybe dette lidt mere: efter alle modulerne er blevet opdateret i unstable så de fungerer med den nye Apache, vil testing-skripterne prøve apache-common og finde ud af at det får alle Apache-modulerne til at holde op med at virke, fordi de har Depends: apache-common (<< den aktuelle version), og de prøver libapache-foo for at finde ud af at den ikke kan overføres fordi den har Depends: apache-common (>= den nye version).

Dog vil de anvende en anden form for logik (nogle gange resultatet af manuel indgriben): de vil ignorere det faktum at apache-common får ting til at holde op med at virke, og fortsætte med ting der virker; hvis det stadig ikke virker efter vi har gjort alt hvad vi kan, er det bare ærgerligt, men måske vil det fungere. Senere vil de prøve alle de tilfældige libapache-foo-pakker og sikre sig at de rent faktisk fungerer.

Når alt har været prøvet, kontrollerer de hvor mange pakker der ikke længere virker, afgører om det er værre eller bedre end det oprindelige, og enten acceptere alt eller glemme det. Du kan se det i update_output.txt på linjerne recur:.

For eksempel:

         recur: [foo bar] baz

betyder i bund og grund har allerede opdaget at foo og bar forbedrer situationen, jeg prøver nu baz for at se hvad der sker, selvom det får ting til at holde op med at virke. Linjerne i update_output.txt som begynder med accepted indikerer at situationen lader til at være blevet forbedret, og linjerne med skipped gør det værre.

Filen update_output.txt er fuldstændig ulæselig!

Det er ikke et spørgsmål. ;-)

Lad os prøve med et eksempel:

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

Dette betyder at hvis cln overføres til testing, vil ginac-cint og libginac-dev ikke kunne installeres i testing på i386. Bemærk at arkitekturene kontrolleres i alfabetisk rækkefølge og kun den første arkitektur med problemer vises - det er grunden til at alpha-arkitekturen vises så ofte.

Linjen got indeholder antallet af problemer i testing på de forskellige arkitekturer (indtil den første arkitektur hvor der findes problemer - se ovenfor). i-45 betyder, at hvis cln blev overført til testing, ville der være 45 pakker på i386 som ikke kan installeres. Nogle af posterne over og under cln viser at der var 43 uinstallérbare pakker i testing på i386, på det tidspunkt.

Linjen skipped: cln (0) (150+4) betyder at der stadig er 150 pakker som skal gennemgås efter denne pakke indtil denne kontrol af alle pakker er gennemført, og at 4 pakker allerede er fundet, som det ikke planlægges at opgradere, fordi de ville ødelægge afhængigheder. (0) er irrelevant og kan roligt ignoreres.

Bemærk at der er flere kontroller af alle pakker i et gennemløg af testing-skriptet.

Jules Bean påbegyndte indsamlingen af de ofte stillede spørgsmål med svar.

Yderligere oplysninger

Nedennævnte sider indeholder yderligere oplysninger om testings aktuelle tilstand og migreringen af pakker fra unstable til testing.

Det kan være interessant at læse en ældre forklarende e-mail. Den eneste mangel er, at den ikke tager højde for pakkepuljen (package pool), fordi denne blev implementeret af James Troup efter e-mail'en blev skrevet.

Koden til testing er tilgængelig fra ftp-master.

Anthony Towns har stået for implementeringen af testing.