Product SiteDocumentation Site

1.6. Livsløpet til en versjon

Debian-prosjektet har tre til seks ulike samtidige versjoner av hvert program med navn Experimental, Unstable, Testing, Stable, Oldstable, til og med Oldoldstable. Hver av dem svarer til forskjellig fase i utviklingen. La oss se på et programs reise fra sin opprinnelige pakke til den kommer med i en stabil versjon av Debian for å forstå hvordan dette henger sammen,.

1.6.1. Statusen Experimental

La oss først se på det spesielle tilfellet med distribusjonen Experimental. Dette er en gruppe Debian-pakker der navnet beskriver at denne programvaren er i utvikling, og ikke nødvendigvis ferdig. Ikke alt passerer gjennom dette trinnet. Noen utviklere legger til pakker her for å få tilbakemeldinger fra mer erfarne (eller modigere) brukere.
Ellers huser denne distribusjonen ofte viktige endringer i grunnpakkene, som, hvis de blir lagt inn i Unstable med alvorlige feil, ville fått kritiske konsekvenser. Den er dermed en helt isolert distribusjon, der pakkene aldri migrerer til en annen versjon (unntatt ved direkte, rask intervensjon fra vedlikeholderen eller FTP-mestrene). Den er heller ikke selvstendig: Bare en undergruppe av de eksisterende pakkene er med i Experimental, og den inneholder vanligvis ikke basissystemet. Denne distribusjonen er derfor nyttigst i kombinasjon med en annen, selvstendig, distribusjon som f.eks. Unstable.

1.6.2. Statusen Unstable

. La oss gå tilbake til tilfellet med en typisk pakke. Utvikleren skaper den første pakken, som de bygger for Unstable-versjonen, og legger den på ftp-master.debian.org-tjeneren. Dette første steget involverer inspeksjon og godkjenning fra FTP-mestrene. Programvaren er deretter tilgjengelig i Unstable-distribusjonen, som er «blodfersk»-distribusjon. Det er brukere som er mer opptatt av å ha oppdaterte pakker, enn av fare for alvorlige feil som velger denne distribusjonen. De vil finne ut mer om programmet, og deretter teste det.
Hvis de treffer på feil, rapporterer de dem til pakkevedlikeholderen. Vedlikeholderen forbereder regelmessig korrigerte versjoner, som lastes opp til tjenermaskinen.
Every newly updated package is updated on all Debian mirrors around the world within six hours. The users then test the corrections and search for other problems resulting from the modifications. Several updates may then occur rapidly. During these times, autobuilder robots come into action. The maintainer uploads the package sources (without any precompiled package). The autobuilders take over and automatically compile versions for all supported architectures. Some compilations may fail; the maintainer will then receive a bug report indicating the problem, which is then to be corrected in the next versions. When the bug is discovered by a specialist for the architecture in question, the bug report may come with a patch ready to use.
Autobyggernes pakkebygging

Figur 1.2. Autobyggernes pakkebygging

1.6.3. Migrasjon til Testing

Senere blir pakken mer moden. Den er bygget på alle arkitekturer, og har ikke blitt endret nylig. Da er den en kandidat for å bli tatt inn i Testing-distribution – en gruppe av Unstable-pakker valgt i henhold til noen målbare kriterier. Hver dag velger et program automatisk pakker som skal med i Testing, etter kriterier som sikrer et visst kvalitetsnivå:
  1. vellykket bygging på alle offisielt støttede arkitekturer;
  2. mangel av kritiske feil, eller i det minste færre enn i den versjon som for tiden er med i Testing;
  3. minst 5 dager brukt i Ustabil, som vanligvis er tilstrekkelig tid til å finne og rapportere eventuelle alvorlige problemer (vellykket passering av pakkens egen testpakke, hvis den har en, reduserer den tiden);
  4. avhengigheter som er tilgjengelig i Testing, eller som i det minste kan flyttes dit sammen med den pakken det gjelder;
  5. automatic quality tests of the package (autopkgtest) — hvis definert – viser ingen regresjon.
Dette systemet er helt klart ikke ufeilbarlig. Kritiske feil finnes ofte i pakker som inngår i Testing. Likevel, det er i alminnelighet effektivt, og Testing gir langt færre problemer enn Unstable, og er for mange et godt kompromiss mellom stabilt og nytt.

1.6.4. Opprykk fra Testing til Stable

La oss gå ut fra at vår pakke nå er kommet med i Testing. Så lenge det er rom for forbedring, må den vedlikeholdsansvarlige fortsette å forbedre den, og starte prosessen fra Unstable (men å få den med i Testing senere går vanligvis raskere: Med mindre den har endret seg betydelig, er alle avhengigheter på plass allerede). Når den er perfekt, er vedlikeholderen ferdig med sitt arbeid. Det neste trinnet er å legge den inn i Stable-distribusjonen, som i realiteten er en enkel kopi av Testing på et tidspunkt valgt av utgivelsesadministratoren. Ideelt sett blir beslutningen tatt når installasjonsprogrammet er ferdig, og når ingen programmer i Testing har noen kjente kritiske feil.
Siden dette øyeblikket i praksis aldri vil inntreffe, må Debian kompromisse: Ta ut pakker der vedlikeholder har unnlatt å rette feil i tide, eller godta i å utgi en distribusjon med noen bugs i blant tusenvis av programmer. Utgiveransvarlig har tidligere annonsert en frys-periode, der hver oppdatering av Testing må godkjennes. Målet her er å forhindre nye versjoner (og dets nye feil), og kun godkjenne oppdateringer som fikser feil.
En pakkes bevegelse gjennom de ulike Debian-versjonene

Figur 1.3. En pakkes bevegelse gjennom de ulike Debian-versjonene

After the release of a new stable version, the Stable Release Managers manage all further development (called “revisions”, ex: 10.1, 10.2, 10.3 for version 10). These updates systematically include all security patches. They will also include the most important corrections (the maintainer of a package must prove the gravity of the problem that they wish to correct in order to have their updates included).
På slutten av reisen er vår hypotetiske pakke nå inkludert i den stabile distribusjonen. Denne reisen, som ikke er uten problemer, forklarer de betydelige forsinkelsene mellom stabile Debianutgivelser. Årsaken til tidsbruket bidrar mer enn noe, til ryktet om høy kvalitet. Videre er de fleste av brukerne fornøyd med en av tre distribusjoner som er tilgjengelig samtidig. Systemadministratorene som fremfor alt er opptatt av stabiliteten til tjenermaskinene sine, trenger ikke den nyeste og beste versjonen av GNOME. De kan velge Debian Stable, og er fornøyd med den. Sluttbrukere som er mer interessert i de nyeste versjonene av GNOME eller KDE Plasma enn i bunnsolid stabilitet, vil finne at Debian Testing er et godt kompromiss mellom fravær av seriøse problemer og relativt oppdatert programvare. Og utviklere og erfarne brukere kan velge å leve på knivseggen og teste de siste nyvinningene i Debian Unstable rett ut av boksen, med fare for å oppleve den hodepine og feil som følger med en ny versjon av et program. Debian til hver især!
Hvordan en pakke beveger seg gjennom Debian kronologisk

Figur 1.4. Hvordan en pakke beveger seg gjennom Debian kronologisk

1.6.5. Statusene Oldstable og Oldoldstable

Hver Stable-utgave har en forventet levetid på ca 5 år, og gitt at utgivelser pleier å komme hvert 2. år, kan det være opp til tre utgivelser som støttes på et gitt tidspunkt. Når en ny stabil utgivelse kommer, blir den tidligere utgivelsen Oldstable, og den enda tidligere Oldoldstable .
Denne langvarige støtten (LTS) for Debian-utgaver er av ny dato. Individuelle bidragsytere og bedrifter har gått sammen om å opprette Debian LTS-gruppen. Eldre utgivelser som ikke lenger støttes av Debians sikkerhetsgruppe kommer inn under ansvarsområdet til denne nye gruppen.
Debian sikkerhetsteam håndterer sikkerhetsstøtte i den til enhver tid aktuelle Stable-utgaven, og også i Oldstable-utgaven (men bare så lenge det er nødvendig for å sikre ett års overlapping med den nåværende stabile utgaven). Dette utgjør om lag tre år med støtte for hver utgivelse. Debian LTS-teamet håndterer de siste (to) år med sikkerhetsstøtte slik at hver utgivelse drar nytte av minst 5 år med støtte, og slik at brukerne kan oppgradere fra versjon N til N + 2, for eksempel fra Debian 9 Stretch to Debian 11 Bullseye.