path: root/danish/devel/testing.wml

#use wml::debian::template title="Debians 'testing'-distribution" BARETITLE=true
#use wml::debian::translation-check translation="8900568ad5473cc15ea75f71f489b4f2b7ae659e"
#include "$(ENGLISHDIR)/releases/info"

<p>For at få generelle, brugerorienterede oplysninger om distributionen 
<q>testing</q>, se <a href="$(DOC)/manuals/debian-faq/ftparchives#testing">Debians 
OSS</a>.</p>

<p>En vigtig ting at bemærke, både for almindelige brugere og udviklerne af
<q>testing</q>, er at sikkerhedsopdateringer til <q>testing</q> <strong>ikke 
varetages af sikkerhedsteamet</strong>.  For flere oplysninger, se 
<a href="../security/faq#testing">sikkerhedsteamets OSS</a>.</p>

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

<h2>Hvordan <q>testing</q> fungerer</h2>

<p><q>Testing</q>-distributionen genereres automatisk.  Den genereres ud fra 
distributionen <q>unstable</q> 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 
<q>testing</q> altid er opfyldt.</p>

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

<ol>
  <li>Den skal have været i <q>unstable</q> i 10, 5 eller 2 dage, afhængigt af hvor 
  meget upload af pakken hastede;</li>

  <li>Den skal være oversat og ajourført på alle arkitekturer som den tidligere
  har været oversat til i <q>unstable</q>;</li>

  <li>Den skal have udgivelseskritiske fejl, som ikke også gælder versionen i 
  <q>testing</q> (se neden for for <a href="#faq">flere oplysninger</a>);</li>

  <li>Alle dens afhængigheder skal <em>enten</em> kunne opfyldes af pakker som
  allerede er i <q>testing</q>, <em>eller</em> skal kunne opfyldes af en gruppe
  pakker som vil blive placeret deri på samme tid;</li>

  <li>Processen med at placere pakken i <q>testing</q> må ikke medføre at andre 
  pakker i <q>testing</q> holder op med at virke. (Se nedenfor for 
  <a href="#faq">flere oplysninger</a>.)</li>
</ol>

<p>En pakke som opfylder de første tre punkter ovenfor, kaldes en <q>Valid 
Candidate</q>.</p>

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

<ul>
  <li><a href="https://release.debian.org/britney/update_excuses.html">\
      Opdateringsundskyldningerne</a>
      [<a href="https://release.debian.org/britney/update_excuses.html.gz">\
      gzip'et</a>]: liste over alle kandiderende pakkeversioner og deres 
      generelle status på deres vej ind i <q>testing</q>; dette er noget kortere og 
      pænere end
  </li>
  <li><a href="https://release.debian.org/britney/update_output.txt">\
      opdateringsuddataene</a>
      [<a href="https://release.debian.org/britney/update_output.txt.gz">\
      gzip'et</a>]: de komplette, noget mere råt udseende uddata fra
      <q>testing</q>-skripterne, efterhånden som de kommer igennem kandidaterne.
  </li>
</ul>

<h2><a name="faq">Ofte stillede/besvarede spørgsmål</a></h2>

# Note to translators: these two first items are almost the same as
# https://www.debian.org/doc/manuals/developers-reference/pkgs.html#faq

<h3><q>Hvad er udgivelseskritiske fejl og hvordan optæller man dem?</q></h3>

<p>Alle fejl med en højere alvorlighedsgrad betragtes som standard, som 
<em><a href="https://bugs.debian.org/release-critical/">udgivelseskritiske</a></em>
(release-critical); for tiden er det <strong>critical</strong> (kritisk), 
<strong>grave</strong> (graverende) og <strong>serious</strong> (alvorlig) 
fejl.</p>

<p>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 <q>testing</q>, og dermed
bliver den heller ikke udgivet i <q>stable</q>.</p>

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


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

<p>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 <tt>acmefoo</tt> overføres til <q>testing</q>, sammen med sine
binære pakker <tt>acme-foo-bin</tt>, <tt>acme-bar-bin</tt>, 
<tt>libacme-foo1</tt> og <tt>libacme-foo-dev</tt>, fjernes den gamle 
version.</p>

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

<p>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 
==, &lt;= or &lt;&lt;.</p>

<p>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 <q>testing</q> 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.</p>

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

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

<p>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.</p>

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

<p>Det vil dermed ikke ske, før en installering af libtool ikke resultere i at
ting, som allerede er i <q>testing</q> holder op med at virke.  Med andre ord, 
indtil alle andre pakker som er afhængige af libltdl<var>Y</var> (hvor 
<var>Y</var> 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 <q>testing</q>.</p>

<p>Her er <a href="https://release.debian.org/britney/update_output.txt">\
tekstuddataene</a> [<a href="https://release.debian.org/britney/update_output.txt.gz">gzip'et</a>]
nyttige: de giver tips (omend meget kortfattede) til hvilke pakker som holder
op med at virke, når en <q>valid candidate</q> overføres til <q>testing</q>
(se <a href="$(DOC)/manuals/developers-reference/pkgs.html#details">Udviklernes 
reference for flere oplysninger</a>).</p>


<h3><q>Hvorfor er det nogle gange svært at få <kbd>Architecture: 
all</kbd>-pakker overført til <q>testing</q>?</q></h3>

<p>Hvis <kbd>Architecture: all</kbd>-pakken skal overføres, skal det være 
muligt at opfylde alle dens afhængigheder på <strong>alle</strong> 
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.</p>

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

<h3><q>Min pakke kommer ikke videre fordi den ikke er ajour for alle 
arkitekturer.  Hvad gør jeg?</q></h3>

<p>Kontroller din pakkes status i
<a href="https://buildd.debian.org/build.php">build-log-databasen</a>.
Hvis pakken ikke bliver oversat, vil den blive markeret som <em>failed</em>;
undersøg build-logfilerne og ret de problemer som eventuelt er forsaget af din
pakkes kildekode.</p>

<p>Hvis du tilfældigvis bemærker at den nye version af pakken er oversat til 
nogle arkitekturer, men ikke viser sig i <q>testing</q>-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.</p>

<p>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
<a href="https://buildd.debian.org/stats/">wanna-build-tilstande</a> (<q>states</q>) 
for at blive helt sikker.</p>

<p>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å 
<a href="$(HOME)/ports/">tilpasningswebsiden</a>, eller tilpasningens 
postliste.</p>

<p>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 <q>ftp.debian.org</q> 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.</p>

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

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

<ul>
  <li>De kan beslutte at beskadigelsen som skyldes overførslen af et nyt
      bibliotek vil gøre ting bedre, fremfor værre, og slippe den igennem 
      sammen med sin flotile af afhængige pakker.</li>
  <li>De kan også manuelt fjerne pakker fra <q>testing</q> som ikke virker, så nye
      ting kan installeres.</li>
</ul>

<h3><q>Har du et rigtigt, ikke-trivielt eksempel?</q></h3>

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

<p>Dog er alle modulpakker til Apache afhængige af <code>apache-common (&gt;=
<var>et-eller-andet</var>), apache-common (&lt;&lt;
<var>et-eller-andet</var>)</code>, 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 <q>testing</q> kan opdateres.</p>

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

<p>Dog vil de anvende en anden form for logik (nogle gange resultatet af manuel 
indgriben):  de vil ignorere det faktum at <tt>apache-common</tt> 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 <strong>vil</strong> det fungere.  Senere vil de prøve alle de tilfældige 
<tt>libapache-<var>foo</var></tt>-pakker og sikre sig at de rent faktisk 
fungerer.</p>

<p>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 <tt>update_output.txt</tt> på 
linjerne <q><code>recur:</code></q>.</p>

<p>For eksempel:</p>

<pre>
         recur: [<var>foo</var> <var>bar</var>] <var>baz</var>
</pre>

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

<h3><q>Filen <tt>update_output.txt</tt> er fuldstændig ulæselig!</q></h3>

<p>Det er ikke et spørgsmål. ;-)</p>

<p>Lad os prøve med et eksempel:</p>

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

<p>Dette betyder at hvis <tt>cln</tt> overføres til <q>testing</q>, vil 
<tt>ginac-cint</tt> og <tt>libginac-dev</tt> ikke kunne installeres i 
<q>testing</q> 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.</p>

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

<p>Linjen <q>skipped: cln (0) (150+4)</q> 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. <q>(0)</q> er irrelevant og kan
roligt ignoreres.</p>

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

<p><em>Jules Bean påbegyndte indsamlingen af de ofte stillede spørgsmål med 
svar</em>.</p>
# Created: Sat Dec  8 12:44:29 GMT 2001

<h2>Yderligere oplysninger</h2>

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

<ul>
    <li>Statistik over binære pakker, der er forældede i
	<a href="https://release.debian.org/britney/testing_outdate.txt">testing</a>,
	<a href="https://release.debian.org/britney/stable_outdate.txt">stable</a></li>
    <li>Afhængighedsproblemer i
	<a href="https://qa.debian.org/debcheck.php?list=INDEX&amp;dist=testing">testing</a>,
	<a href="https://qa.debian.org/debcheck.php?list=INDEX&amp;dist=stable">stable</a></li>
</ul>

<p>Det kan være interessant at læse en ældre 
<a href="https://lists.debian.org/debian-devel-0008/msg00906.html">\
forklarende e-mail</a>.  Den eneste mangel er, at den ikke tager højde for
pakkepuljen (<q>package pool</q>), fordi denne blev implementeret af James Troup
efter e-mail'en blev skrevet.</p>

<p>Koden til testing er tilgængelig fra
<a href="https://release.debian.org/britney/update_out_code/">\
ftp-master</a>.</p>

<p><em>Anthony Towns har stået for implementeringen af <q>testing</q>.</em></p>