Re: debian-faq/de/ diffs: choosing.sgml
Hallo Jens,
> Bitte versuche andere Zeilenumbrüche zu vermeiden. Soweit ich sehe, hast
> du nach "benutzt" ein Komma eingefügt und keine weiteren Änderungen
> beabsichtigt (obwohl du ein "an an" drin hast).
> Hättest du die Zeilenumbrüche nicht geändert, so hättest du deinen
> Fehler auch sofort entdeckt, da man dann nur
>
> - <item>Nun entdeckt am 25. Juni jemand der testing oder unstable benutzt
> + <item>Nun entdeckt am 25. Juni jemand der testing oder unstable benutzt,
>
> erwarten würde.
Ok.
>
> > Veröffentlichung gemacht wurde, oder nicht.
> > <item>Pakete wandern fortwährend von sid nach testing (beispielsweise
> > &testingreleasename;). Aber Pakete in stable (beispielsweise
&releasename;)
> > - bleiben immer diesselben, außer im Falle von Sicherheitsupdates.
> > - <item>Nach einer bestimmten Zeit wird testing eingefroren; wird aber
> > - weiterhin als testing bezeichnet. Von nun an gelangen keine Pakete
> > + bleiben immer die selben, außer im Falle von Sicherheitsupdates.
> > + <item>Nach einer bestimmten Zeit wird testing eingefroren; wird aber
> > + weiterhin als testing bezeichnet. Von nun an gelangen keine Pakete
>
> Solche Änderungen in der Einrückung sind eigentlich auch unnötig und
> machen das Korrekturlesen nur komplizierter. Könntest du solche Dinge
> nach Möglichkeit in einem separaten Patch schicken, da sowas ja nicht
> gelesen werden muss (diff mit Option -b würde ich zum Überprüfen eines
> solches Patches wählen, da dies keine Ausgabe haben solle)?
Ok.
>
> Der Patch sieht abgesehen davon sehr gut aus. Sende mir bitte noch
> mal zwei kleine Patches (einer nur mit Rechtschreibfehlern, der andere
> nur mit Änderungen der Einrückungen), beide ohne andere Zeilenumbrüche.
In der ersten Datei sind die svn-diffs mit Rechtschreibfehlern.
In der zweiten sind diffs noch dazu mit den alten Einrückungen und Umbrüchen,
wie in der Orginaldatei.
(In einer dritten sind mit dem Tool diff und Option -b (nicht svn diff)
aufgelistet.)
Gruß,
Martin
Index: choosing.sgml
===================================================================
--- choosing.sgml (Revision 5335)
+++ choosing.sgml (Arbeitskopie)
@@ -13,7 +13,7 @@
<p>Um mehr Informationen über die verfügbaren Distributionen zu erhalten,
lesen Sie bitte <ref id="dists">.
-<sect>Welche Debian-Distribution (stable/testing/unstable) is geeignet für
+<sect>Welche Debian-Distribution (Stable/Testing/Unstable) ist geeignet für
mich?
<p>Die Antwort darauf ist ein wenig kompliziert. Sie hängt sehr davon ab, was
@@ -31,7 +31,7 @@
installieren wollen, beginnen Sie mit stable. Ein Teil der enthaltenen
Software ist zwar etwas veraltet, dafür handelt es sich um die am wenigsten
mit Softwarefehlern belastete Arbeitsumgebung. Sobald Sie es sich dann
-zutrauen, können Sie mit wenig Aufwand zum etwas moderneren unstable
+zutrauen, können Sie mit wenig Aufwand zum etwas moderneren Unstable
wechseln.</p>
<item><p>Wenn Sie Desktop-Benutzer sind, bereits über etwas Erfahrung mit
@@ -41,7 +41,7 @@
<item><p>Wenn Sie einen Server betreiben, besonders einen, an den hohe
Anforderungen hinsichtlich der Stabilität gestellt werden oder der über das
-Internet erreichbar ist, sollten Sie stable installieren. Das ist bei weitem
+Internet erreichbar ist, sollten Sie Stable installieren. Das ist bei weitem
die beste und sicherste Wahl hierfür.</p>
</list>
@@ -49,16 +49,16 @@
<p>The folgenden Fragen beleuchten die verschiedenen Wahlmöglichkeiten
(hoffentlich) etwas detaillierter.</p>
-<sect1>Sie haben mir empfohlen, stable zu installieren. Allerdings wird unter
+<sect1>Sie haben mir empfohlen, Stable zu installieren. Allerdings wird unter
stable bestimmte Hardware nicht erkannt oder funktioniert nicht richtig. Was
soll ich tun?
<p>Durchsuchen Sie das Web mithilfe einer Suchmaschine und schauen Sie nach,
ob jemand anderes Ihre Hardware zum Laufen gebracht hat. Die allermeiste
-Hardware sollte gut unter stable funktionieren. Wenn Sie aber bestimmte, sehr
-neue Hardware haben, kann es sein, dass diese nicht unter stable funktioniert.
-Sollte das der Fall sein, möchten Sie vielleicht zu unstable upgraden
-beziehungsweise unstable installieren.</p>
+Hardware sollte gut unter Stable funktionieren. Wenn Sie aber bestimmte, sehr
+neue Hardware haben, kann es sein, dass diese nicht unter Stable funktioniert.
+Sollte das der Fall sein, möchten Sie vielleicht zu Unstable upgraden
+beziehungsweise Unstable installieren.</p>
<p>Für Laptops ist die Internetseite <url
id="http://www.linux-on-laptops.com/";> eine sehr gute Anlaufstelle, um
@@ -83,33 +83,33 @@
Distributionen?
<p>Ja. Unstable hat die aktuellsten (jüngsten) Versionen. Allerdings sind die
-Pakete in unstable nicht ausführlich getestet und haben möglicherweise
+Pakete in Unstable nicht ausführlich getestet und haben möglicherweise
Fehler.</p>
-<p>Andererseits enthält stable zwar alte Paketversionen, diese sind jedoch
+<p>Andererseits enthält Stable zwar alte Paketversionen, diese sind jedoch
ausführlich getestet. Es ist weniger wahrscheinlich, dass sie Fehler
enthalten.</p>
-<p>Die Pakete in testing stellen den Mittelweg zwischen diesen beiden Extremen
+<p>Die Pakete in Testing stellen den Mittelweg zwischen diesen beiden Extremen
dar.</p>
<sect1>Die stabile Distribution enthält wirklich eine ganze Menge ziemlich
veralteter Pakete, wie an Kde, Gnome, Xorg oder sogar dem Kernel deutlich
erkennbar ist. Warum ist das so?
-<p>Da könnten Sie recht haben. Das Alter der Pakete in stable hängt davon ab,
+<p>Da könnten Sie recht haben. Das Alter der Pakete in Stable hängt davon ab,
wann die letzte Veröffentlichung gemacht wurde. Angesichts dessen, dass
üblicherweise mehr als ein Jahr zwischen den Veröffentlichungen von Debian
-liegen, kann es sein, dass Sie den Eindruck gewinnen, dass stable alte Pakete
+liegen, kann es sein, dass Sie den Eindruck gewinnen, dass Stable alte Pakete
enthält. Allerdings wurden diese durch und durch getestet. Man kann guten
Gewissens sagen, dass diese Pakete keine schweren Fehler, Sicherheitslücken
und dergleichen enthalten. Diese Eigenschaft ist sehr wichtig für produktive
Server, die 24 Stunden am Tag und sieben Tage die Woche funktionieren
müssen.</p>
-<p>Umgekehrt können Pakete in testing und unstable versteckte Fehler,
+<p>Umgekehrt können Pakete in Testing und Unstable versteckte Fehler,
Sicherheitslöcher und Ähnliches aufweisen. Schlimmer noch, manche Pakete in
-testing und unstable funktionieren möglicherweise nicht wie beabsichtigt. Für
+Testing und Unstable funktionieren möglicherweise nicht wie beabsichtigt. Für
gewöhnlich ziehen Personen, die an einem einzelnen Desktop-Rechner arbeiten,
die jüngsten und modernsten Paket-Sets vor. Unstable ist die richtige Wahl für
diese Art von Benutzer.</p>
@@ -123,21 +123,21 @@
<p>Ja, aber das ist eine Einbahnstraße. Sie können von stable --> testing
--> unstable wechseln. Aber in umgekehrter Richtung ist das nicht
-"möglich". Sie sollten Sich also sicher sein, wenn sie planen unstable zu
+"möglich". Sie sollten Sich also sicher sein, wenn sie planen Unstable zu
installieren oder ein upgrade zu machen.</p>
<p>Tatsächlich verhält es sich so: Wenn Sie Experte sind und willens etwas
Zeit darauf zu verwenden, vorsichtig sind und wissen, was Sie tun, dann kann
-es möglich sein, von unstable zu testing und von testing dann zu stable zu
+es möglich sein, von Unstable zu Testing und von Testing dann zu Stable zu
gehen. Das Installations-Skript ist allerdings nicht dafür entworfen,
dergleichen zu tun. Daher kann es passieren, dass während des Vorgangs Ihre
Konfigurationsdateien verloren gehen und ...
-<sect1>Sollte man testing oder unstable installieren?
+<sect1>Sollte man Testing oder Unstable installieren?
<p>Das ist eine ziemlich subjektive Angelegenheit. Es gibt darauf keine
absolut richtige Antwort, sondern lediglich eine "vernünftige Vermutung", um
-sich zwischen testing und stable zu entscheiden. Die Sache ist die:</p>
+sich zwischen Testing und Stable zu entscheiden. Die Sache ist die:</p>
<p><list>
@@ -147,22 +147,22 @@
dann dauert es eine ganze Weile, bis die Dinge wieder im Lot sind. Manchmal
kann das Tage dauern, hin und wieder auch Monate.</p>
-<item>In unstable ändert sich sehr viel und es kann daher auch jederzeit
+<item>In Unstable ändert sich sehr viel und es kann daher auch jederzeit
kaputt gehen. Allerdings werden die Probleme in vielen Fällen binnen Tagen
-behoben und unstable bietet außerdem immer die neueste für Debian paketierte
+behoben und Unstable bietet außerdem immer die neueste für Debian paketierte
Software.
</list>
-<p>Aber manchmal kann es günstiger sein, testing mitzuverfolgen als unstable.
+<p>Aber manchmal kann es günstiger sein, Testing mitzuverfolgen als unstable.
Der Autor dieser Dokumentation erlebte so etwas während dem Wechsel von gcc3
auf gcc4: Er versuchte, das Paket <package>labplot</package> auf einem Rechner
-zu installieren, der unstable folgte. Das gelang nicht, da nur einige der
+zu installieren, der Unstable folgte. Das gelang nicht, da nur einige der
Abhängigkeiten im Zuge des gcc-Übergangs bereits erfüllt waren, andere jedoch
-nicht. In testing ließ sich das Paket dagegen installieren, da die im Übergang
+nicht. In Testing ließ sich das Paket dagegen installieren, da die im Übergang
befindlichen Pakete noch nicht in dort angelangt waren.</p>
-<sect1>Hier ist die Rede davon, dass testing "kaputt" gehen kann. Was soll das
+<sect1>Hier ist die Rede davon, dass Testing "kaputt" gehen kann. Was soll das
heißen?
<p>Es kann vorkommen, dass sich ein Paket nicht mit den
@@ -174,54 +174,54 @@
<p>Wenn solche Dinge passieren, sagt man von einer Distribution, dass sie
(zumindest in Bezug auf dieses eine Paket) kaputt ist.</p>
-<sect1>Wie kann es sein, das testing monatelang kaputt ist? Würden die in
-unstable eingepflegten Fehlerkorrekturen nicht direkt in testing einfließen?
+<sect1>Wie kann es sein, dass Testing monatelang kaputt ist? Würden die in
+Unstable eingepflegten Fehlerkorrekturen nicht direkt in Testing einfließen?
-<p>Die Fehlerkorrekturen und Verbesserungen aus der Distribution unstable
-gelangen nur langsam nach einer bestimmten Anzahl von Tagen nach testing.
-Nehmen wir an, dieser Wert liegt bei zehn Tagen. Die Pakete in unstable
-gelangen erst nach testing, wenn dafür keine neuen veröffentlichungskritischen
+<p>Die Fehlerkorrekturen und Verbesserungen aus der Distribution Unstable
+gelangen nur langsam nach einer bestimmten Anzahl von Tagen nach Testing.
+Nehmen wir an, dieser Wert liegt bei zehn Tagen. Die Pakete in Unstable
+gelangen erst nach Testing, wenn dafür keine neuen veröffentlichungskritischen
Fehler mehr gemeldet werden. Wenn also ein veröffentlichungskritischer Fehler
-für das Paket vorliegt, wird es auch nicht nach zehn Tagen nach testing
+für das Paket vorliegt, wird es auch nicht nach zehn Tagen nach Testing
gelangen.</p>
<p>Die Idee ist folgende: wenn das Paket irgendwelche Fehler hat, dann würden
-diese von Benutzern entdeckt werden, die unstable verwenden und würden
-bereinigt, bevor das Paket nach testing kommt. Das hält testing für die meiste
+diese von Benutzern entdeckt werden, die Unstable verwenden und würden
+bereinigt, bevor das Paket nach Testing kommt. Das hält Testing für die meiste
Zeit in einem benutzbaren Zustand. Insgesamt ein brillantes Konzept. Allerdings
sind die Dinge nicht immer so einfach. Überdenken Sie folgende Situation:</p>
<p><list>
<item>Stellen Sie sich vor, Sie wären am Paket XYZ.dd interessiert.
- <item>Nehmen wir an, dass am 10. Juni die Version XYZ-3.6 in testing
+ <item>Nehmen wir an, dass am 10. Juni die Version XYZ-3.6 in Testing
ist und Version XYZ-3.7 in unstable.
- <item>Nach zehn Tagen wandert XYZ-3.7 von unstable nach testing.
- <item>Also haben am 20. Juni sowohl testing als auch unstable XYZ-3.7 in
+ <item>Nach zehn Tagen wandert XYZ-3.7 von Unstable nach Testing.
+ <item>Also haben am 20. Juni sowohl Testing als auch Unstable XYZ-3.7 in
ihren Repositories.
- <item>Sagen wir, ein Benutzer der testing-Distribution bemerkt, dass ein
+ <item>Sagen wir, ein Benutzer der Testing-Distribution bemerkt, dass ein
neues XYZ-Paket verfügbar ist und macht ein Update von XYT-3.6 zu
XYZ-3.7.
- <item>Nun entdeckt am 25. Juni jemand der testing oder unstable benutzt
- einen veröffentlichungskritischen Fehler im XYZ-3.7 und meldet diesen an
+ <item>Nun entdeckt am 25. Juni jemand der Testing oder Unstable benutzt,
+ einen veröffentlichungskritischen Fehler im XYZ-3.7 und meldet diesen an
das BTS.
<item>Der Betreuer von XYZ behebt den Fehler und lädt ein neues Paket
- nach unstable hoch, sagen wir am 30. Juni. Wir nehmen hierbei an, dass
+ nach Unstable hoch, sagen wir am 30. Juni. Wir nehmen hierbei an, dass
der Betreuer fünf Tage braucht, um den Fehler zu beheben und die neue
Version hochzuladen. Die Zahl von fünf Tagen sollte hier nicht falsch
verstanden werden. Es kann länger dauern oder auch nicht, in
Abhängigkeit von der Schwere des vorliegenden
veröffentlichungskritischen Fehlers.
<item>Die neue Version ist nun in unstable. Laut Plan soll XYZ-3.8
- daraufhin testing am 10. Juli erreichen.
+ daraufhin Testing am 10. Juli erreichen.
<item>Aber schon am 5. Juli entdeckt wieder jemand einen
veröffentlichungskritischen Fehler in XYZ-3.8.
- <item>Nehmen wir an, der Betreuen löst das Problem und lädt die neue
+ <item>Nehmen wir an, der Betreuer löst das Problem und lädt die neue
Version von XYZ nach fünf Tagen hoch.
- <item>Also ist am 10. Juli XYZ-3.7 in testing und XYZ-3.9 in unstable.
+ <item>Also ist am 10. Juli XYZ-3.7 in Testing und XYZ-3.9 in unstable.
<item>Die neue Version XYZ-3.9 soll nach dem neuen Zeitplan nun am 20.
- Juli in testing ankommen.
- <item>Nachdem Sie ja testing verwenden und XYZ-3.7 fehlerhaft ist,
+ Juli in Testing ankommen.
+ <item>Nachdem Sie ja Testing verwenden und XYZ-3.7 fehlerhaft ist,
könnten sie wahrscheinlich XYZ erst wieder nach dem 20. Juli benutzen.
Im Endeffekt hätten Sie dann rund einen Monat lang ein kaputtes Paket XYZ
gehabt.
@@ -230,7 +230,7 @@
<p>Die Angelegenheit kann noch weitaus komplizierter werden, wenn etwa XYZ von
vier anderen Paketen abhängt. Das kann dann zu einer monatelang nicht
-benutzbaren testing-Distribution führen. Das soeben vorgestellte Szenario ist
+benutzbaren Testing-Distribution führen. Das soeben vorgestellte Szenario ist
zwar konstruiert, kann aber im echten Leben tatsächlich vorkommen. Allerdings
geschieht das nur selten.
@@ -240,10 +240,10 @@
<p>Einer der Gründe, warum viele Leute Debian anderen Linux-Distributionen
vorziehen, ist der, dass es nur sehr wenig Verwaltungsaufwand erfordert. Diese
Leute wollen ein System, das einfach nur funktioniert. Im allgemeinen kann man
-sagen, dass stable nur sehr wenig Wartung bedarf, während testing und unstable
-nach fortwährender Pflege durch den Systemwerwalter verlangen. Wenn Sie stable
+sagen, dass Stable nur sehr wenig Wartung bedarf, während Testing und Unstable
+nach fortwährender Pflege durch den Systemverwalter verlangen. Wenn Sie Stable
verwenden, müssen Sie lediglich darauf achten, mit den Sicherheitsupdates
-Schritt zu halten. Wenn Sie testing oder unstable verwenden, ist es klug, ein
+Schritt zu halten. Wenn Sie Testing oder Unstable verwenden, ist es klug, ein
Auge auf neu entdeckte Fehler, Fehlerberichtigungen und neue Fähigkeiten in
den bereits installierten Paketen zu haben.</p>
@@ -270,26 +270,26 @@
testing = &testingreleasename;; unstable = sid
<item>Unstable wird immer sid genannte, unabhängig davon, ob eine
Veröffentlichung gemacht wurde, oder nicht.
- <item>Pakete wandern fortwährend von sid nach testing (beispielsweise
- &testingreleasename;). Aber Pakete in stable (beispielsweise &releasename;)
- bleiben immer diesselben, außer im Falle von Sicherheitsupdates.
- <item>Nach einer bestimmten Zeit wird testing eingefroren; wird aber
- weiterhin als testing bezeichnet. Von nun an gelangen keine Pakete
- von unstable nach testing mehr, es sei denn, um veröffentlichungskritische
+ <item>Pakete wandern fortwährend von sid nach Testing (beispielsweise
+ &testingreleasename;). Aber Pakete in Stable (beispielsweise &releasename;)
+ bleiben immer die selben, außer im Falle von Sicherheitsupdates.
+ <item>Nach einer bestimmten Zeit wird Testing eingefroren; wird aber
+ weiterhin als Testing bezeichnet. Von nun an gelangen keine Pakete
+ von Unstable nach Testing mehr, es sei denn, um veröffentlichungskritische
(RC) Fehler zu beheben.
- <item>Nachdem testing eingefroren wurde, müssen alle neu eingeführten
+ <item>Nachdem Testing eingefroren wurde, müssen alle neu eingeführten
Fehlerkorrekturen händisch durch die Mitglieder des Veröffentlichungs-Teams
überprüft werden. Das soll sicherstellen, dass sich keine ernsthaften Fehler
- in die eingefrorene testing-Veröffentlichung mehr einschleichen können.
- <item>Die RC-Fehler im eingefrorenen testing werden auf Null reduziert.
- <item>Das eingefrorene testing wird ohne RC-Fehler als neue stabile
+ in die eingefrorene Testing-Veröffentlichung mehr einschleichen können.
+ <item>Die RC-Fehler im eingefrorenen Testing werden auf Null reduziert.
+ <item>Das eingefrorene Testing wird ohne RC-Fehler als neue stabile
Veröffentlichung herausgegeben. In unserem Beispiel würde diese neue
Veröffentlichung &testingreleasename; genannt werden.
<item>Nun ist oldstable = &releasename;, stable = &testingreleasename;. Zu
- diesem Zeitpunkt entsprechen sich der Inhalt von stable und eingefrorenem
- testing.
- <item>Ein neues testing wird aus dem derzeitigen stable abgeleitet.
- <item>Pakete beginnen wieder aus sid nach testing herunterzukommen und die
+ diesem Zeitpunkt entsprechen sich der Inhalt von Stable und eingefrorenem
+ Testing.
+ <item>Ein neues Testing wird aus dem derzeitigen Stable abgeleitet.
+ <item>Pakete beginnen wieder aus sid nach Testing herunterzukommen und die
Debian-Gemeinschaft beginnt auf die nächste Veröffentlichung hinzuarbeiten.
</list>
@@ -309,11 +309,12 @@
<p>Sie können außerdem <prgn>lsb_release</prgn> abfragen (verfügbar über das
<package>lsb-release</package> Paket). Wenn Sie dieses Programm auf einem
-System mit unstable ausführen, erhalten Sie Folgendes:
+System mit Unstable ausführen, erhalten Sie Folgendes:
<example>
$ lsb_release -a
-LSB Version: core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:core-2.0-ia32:core-3.0-ia32:core-3.1-ia32
+LSB Version: core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:
+ core-2.0-ia32:core-3.0-ia32:core-3.1-ia32
Distributor ID: Debian
Description: Debian GNU/Linux unstable (sid)
Release: unstable
@@ -327,27 +328,27 @@
verwendet. So etwas wird häufig als apt-pinning bezeichnet. Solche Systeme
verwenden wahrscheinlich einen Mix aus unterschiedlichen Distributionen.
-<sect1>Augenblicklich verwende ich stable. Kann ich zu testing oder unstable
+<sect1>Augenblicklich verwende ich stable. Kann ich zu Testing oder Unstable
wechseln? Und wenn, wie?
-<p>Wenn Sie derzeitig stable einsetzen, dann wird in der Datei
+<p>Wenn Sie derzeitig Stable einsetzen, dann wird in der Datei
<file>/etc/apt/sources.list</file> das dritte Feld entweder &releasename; oder
stable sein. Diesen Eintrag müssen Sie passend zu der Distribution ändern, die
-Sie verwenden möchten. Wenn das testing ist, dann ändern Sie das dritte Feld von
-<file>/etc/apt/sources.list</file> in testing. Wenn Sie unstable verwenden
-wollen, dann tragen Sie in das dritte Feld unstable ein.
+Sie verwenden möchten. Wenn das Testing ist, dann ändern Sie das dritte Feld von
+<file>/etc/apt/sources.list</file> in Testing. Wenn Sie Unstable verwenden
+wollen, dann tragen Sie in das dritte Feld Unstable ein.
-<p>Gegenwärtig wird testing &testingreleasename; genannt. Wennn Sie das dritte
+<p>Gegenwärtig wird Testing &testingreleasename; genannt. Wennn Sie das dritte
Feld von <file>/etc/apt/sources.list</file> in &testingreleasename; ändern, dann
-werden Sie künftig testing verwenden. Aber auch wenn &testingreleasename; stable
+werden Sie künftig Testing verwenden. Aber auch wenn &testingreleasename; stable
wird, werden Sie weiterhin &testingreleasename; haben.</p>
<p>Unstable wird immer sid genannt. Wenn Sie also das dritte Feld von
-<file>/etc/apt/sources.list</file> in sid ändern, werden Sie stets unstable folgen.
+<file>/etc/apt/sources.list</file> in sid ändern, werden Sie stets Unstable folgen.
-<p>Gegenwärtig bietet Debian Sicherheitsupdates für testing aber nicht für
-unstable an, da Fehlerkorrekturen für unstable direkt im Hauptarchiv vorgenommen
-werden. Wenn Sie also unstable benutzen, sollten Sie sicherstellen, dass Sie die
+<p>Gegenwärtig bietet Debian Sicherheitsupdates für Testing aber nicht für
+Unstable an, da Fehlerkorrekturen für Unstable direkt im Hauptarchiv vorgenommen
+werden. Wenn Sie also Unstable benutzen, sollten Sie sicherstellen, dass Sie die
Zeilen in <file>/etc/apt/sources.list</file> entfernen, die sich auf
Sicherheitsupdates beziehen.
@@ -357,12 +358,12 @@
Veröffentlichungshinweise enthalten möglicherweise Informationen über die Art,
wie Sie das Upgrade vornehmen sollten.
-<p>Dennoch können Sie nachdem sich die obigen Veränderungen vorgenommen haben,
+<p>Dennoch können Sie, nachdem Sie die obigen Veränderungen vorgenommen haben,
<prgn>aptitude update</prgn> laufen lassen und dann die Pakete installieren,
die Sie haben möchten. Beachten Sie, dass das Installieren eines Pakets aus
einer anderen Distribution möglicherweise automatisch gleich Ihr halbes System
einem Upgrade unterzieht. Wenn Sie einzelne Pakete installieren, haben Sie zum
-Schluß ein System, auf denen eine Mischung verschiedener Distributionen läuft.
+Schluss ein System, auf denen eine Mischung verschiedener Distributionen läuft.
<p>In bestimmten Situationen ist es daher wahrscheinlich das Beste, ein volles
Upgrade auf die neue Distribution zu machen, indem man <prgn>apt-get
@@ -370,14 +371,14 @@
full-upgrade</prgn> benutzt. Lesen Sie die Handbuchseiten von apt und aptitude
für weiterführende Informationen.
-<sect1>Im Augenblick verwende ich testing (&testingreleasename;). Was wird
+<sect1>Im Augenblick verwende ich Testing (&testingreleasename;). Was wird
passieren, wenn eine neue Veröffentlichung herauskommt? Werde ich weiterhin
-testing haben oder wird auf meinem Rechner die neue stabile Distribution
+Testing haben oder wird auf meinem Rechner die neue stabile Distribution
laufen?
<p>Das hängt von den Einträgen in der Datei <file>/etc/apt/sources.list</file>
-ab. Wenn Sie gegenwärtig testing mitverfolgen, sollt diese Einträge in etwa so
-aussehen:
+ab. Wenn Sie gegenwärtig Testing mitverfolgen, sollten diese Einträge in etwa
+so aussehen:
<example>
deb http://ftp.us.debian.org/debian/ testing main
@@ -390,14 +391,14 @@
</example>
<p>Wenn das dritte Feld in <file>/etc/apt/sources.list</file> 'testing' ist,
-dann werden Sie auch nach der Veröffentlichung noch testing haben. Nachdem
+dann werden Sie auch nach der Veröffentlichung noch Testing haben. Nachdem
&testingreleasename; veröffentlicht wurde, werden Sie eine neue
Debian-Distribution mit einem anderen Codenamen laufen haben. Am Anfang werden
die Veränderungen nicht auffällig sein. Das wird sich aber ändern, sobald neue
-Pakete von unstable in die testing-Distribution kommen.</p>
+Pakete von Unstable in die Testing-Distribution kommen.</p>
<p>Wenn aber das dritte Feld '&testingreleasename;' enthält, dann werden Sie
-künftig stable installiert haben, weil &testingreleasename; dann die neue
+künftig Stable installiert haben, weil &testingreleasename; dann die neue
stabile Veröffentlichung sein wird.</p>
<sect1>Ich bin noch immer verwirrt. Was sagten Sie, solle ich installieren?
@@ -476,7 +477,7 @@
der Paketwerkzeuge zu machen, da Sie am Ende möglicherweise mit einem
unbrauchbaren System dastehen.
-<p>Wenn sich all Ihre Benutzerdaten (beispielsweise <file>/home</file>) auf
+<p>Wenn sich alle Ihre Benutzerdaten (beispielsweise <file>/home</file>) auf
einer gesonderten Partition befinden, ist der Umstieg auf Debian ziemlich
einfach. Sie müssen das Installationssystem lediglich anweisen, diese
Partition bei der Neuinstallation einzubinden (aber nicht zu formatieren).
Index: choosing.sgml
===================================================================
--- choosing.sgml (Revision 5335)
+++ choosing.sgml (Arbeitskopie)
@@ -13,7 +13,7 @@
<p>Um mehr Informationen über die verfügbaren Distributionen zu erhalten,
lesen Sie bitte <ref id="dists">.
-<sect>Welche Debian-Distribution (stable/testing/unstable) is geeignet für
+<sect>Welche Debian-Distribution (Stable/Testing/Unstable) ist geeignet für
mich?
<p>Die Antwort darauf ist ein wenig kompliziert. Sie hängt sehr davon ab, was
@@ -31,7 +31,7 @@
installieren wollen, beginnen Sie mit stable. Ein Teil der enthaltenen
Software ist zwar etwas veraltet, dafür handelt es sich um die am wenigsten
mit Softwarefehlern belastete Arbeitsumgebung. Sobald Sie es sich dann
-zutrauen, können Sie mit wenig Aufwand zum etwas moderneren unstable
+zutrauen, können Sie mit wenig Aufwand zum etwas moderneren Unstable
wechseln.</p>
<item><p>Wenn Sie Desktop-Benutzer sind, bereits über etwas Erfahrung mit
@@ -41,7 +41,7 @@
<item><p>Wenn Sie einen Server betreiben, besonders einen, an den hohe
Anforderungen hinsichtlich der Stabilität gestellt werden oder der über das
-Internet erreichbar ist, sollten Sie stable installieren. Das ist bei weitem
+Internet erreichbar ist, sollten Sie Stable installieren. Das ist bei weitem
die beste und sicherste Wahl hierfür.</p>
</list>
@@ -49,16 +49,16 @@
<p>The folgenden Fragen beleuchten die verschiedenen Wahlmöglichkeiten
(hoffentlich) etwas detaillierter.</p>
-<sect1>Sie haben mir empfohlen, stable zu installieren. Allerdings wird unter
+<sect1>Sie haben mir empfohlen, Stable zu installieren. Allerdings wird unter
stable bestimmte Hardware nicht erkannt oder funktioniert nicht richtig. Was
soll ich tun?
<p>Durchsuchen Sie das Web mithilfe einer Suchmaschine und schauen Sie nach,
ob jemand anderes Ihre Hardware zum Laufen gebracht hat. Die allermeiste
-Hardware sollte gut unter stable funktionieren. Wenn Sie aber bestimmte, sehr
-neue Hardware haben, kann es sein, dass diese nicht unter stable funktioniert.
-Sollte das der Fall sein, möchten Sie vielleicht zu unstable upgraden
-beziehungsweise unstable installieren.</p>
+Hardware sollte gut unter Stable funktionieren. Wenn Sie aber bestimmte, sehr
+neue Hardware haben, kann es sein, dass diese nicht unter Stable funktioniert.
+Sollte das der Fall sein, möchten Sie vielleicht zu Unstable upgraden
+beziehungsweise Unstable installieren.</p>
<p>Für Laptops ist die Internetseite <url
id="http://www.linux-on-laptops.com/";> eine sehr gute Anlaufstelle, um
@@ -83,33 +83,33 @@
Distributionen?
<p>Ja. Unstable hat die aktuellsten (jüngsten) Versionen. Allerdings sind die
-Pakete in unstable nicht ausführlich getestet und haben möglicherweise
+Pakete in Unstable nicht ausführlich getestet und haben möglicherweise
Fehler.</p>
-<p>Andererseits enthält stable zwar alte Paketversionen, diese sind jedoch
+<p>Andererseits enthält Stable zwar alte Paketversionen, diese sind jedoch
ausführlich getestet. Es ist weniger wahrscheinlich, dass sie Fehler
enthalten.</p>
-<p>Die Pakete in testing stellen den Mittelweg zwischen diesen beiden Extremen
+<p>Die Pakete in Testing stellen den Mittelweg zwischen diesen beiden Extremen
dar.</p>
<sect1>Die stabile Distribution enthält wirklich eine ganze Menge ziemlich
veralteter Pakete, wie an Kde, Gnome, Xorg oder sogar dem Kernel deutlich
erkennbar ist. Warum ist das so?
-<p>Da könnten Sie recht haben. Das Alter der Pakete in stable hängt davon ab,
+<p>Da könnten Sie recht haben. Das Alter der Pakete in Stable hängt davon ab,
wann die letzte Veröffentlichung gemacht wurde. Angesichts dessen, dass
üblicherweise mehr als ein Jahr zwischen den Veröffentlichungen von Debian
-liegen, kann es sein, dass Sie den Eindruck gewinnen, dass stable alte Pakete
+liegen, kann es sein, dass Sie den Eindruck gewinnen, dass Stable alte Pakete
enthält. Allerdings wurden diese durch und durch getestet. Man kann guten
Gewissens sagen, dass diese Pakete keine schweren Fehler, Sicherheitslücken
und dergleichen enthalten. Diese Eigenschaft ist sehr wichtig für produktive
Server, die 24 Stunden am Tag und sieben Tage die Woche funktionieren
müssen.</p>
-<p>Umgekehrt können Pakete in testing und unstable versteckte Fehler,
+<p>Umgekehrt können Pakete in Testing und Unstable versteckte Fehler,
Sicherheitslöcher und Ähnliches aufweisen. Schlimmer noch, manche Pakete in
-testing und unstable funktionieren möglicherweise nicht wie beabsichtigt. Für
+Testing und Unstable funktionieren möglicherweise nicht wie beabsichtigt. Für
gewöhnlich ziehen Personen, die an einem einzelnen Desktop-Rechner arbeiten,
die jüngsten und modernsten Paket-Sets vor. Unstable ist die richtige Wahl für
diese Art von Benutzer.</p>
@@ -123,21 +123,21 @@
<p>Ja, aber das ist eine Einbahnstraße. Sie können von stable --> testing
--> unstable wechseln. Aber in umgekehrter Richtung ist das nicht
-"möglich". Sie sollten Sich also sicher sein, wenn sie planen unstable zu
+"möglich". Sie sollten Sich also sicher sein, wenn sie planen Unstable zu
installieren oder ein upgrade zu machen.</p>
<p>Tatsächlich verhält es sich so: Wenn Sie Experte sind und willens etwas
Zeit darauf zu verwenden, vorsichtig sind und wissen, was Sie tun, dann kann
-es möglich sein, von unstable zu testing und von testing dann zu stable zu
+es möglich sein, von Unstable zu Testing und von Testing dann zu Stable zu
gehen. Das Installations-Skript ist allerdings nicht dafür entworfen,
dergleichen zu tun. Daher kann es passieren, dass während des Vorgangs Ihre
Konfigurationsdateien verloren gehen und ...
-<sect1>Sollte man testing oder unstable installieren?
+<sect1>Sollte man Testing oder Unstable installieren?
<p>Das ist eine ziemlich subjektive Angelegenheit. Es gibt darauf keine
absolut richtige Antwort, sondern lediglich eine "vernünftige Vermutung", um
-sich zwischen testing und stable zu entscheiden. Die Sache ist die:</p>
+sich zwischen Testing und Stable zu entscheiden. Die Sache ist die:</p>
<p><list>
@@ -147,22 +147,22 @@
dann dauert es eine ganze Weile, bis die Dinge wieder im Lot sind. Manchmal
kann das Tage dauern, hin und wieder auch Monate.</p>
-<item>In unstable ändert sich sehr viel und es kann daher auch jederzeit
+<item>In Unstable ändert sich sehr viel und es kann daher auch jederzeit
kaputt gehen. Allerdings werden die Probleme in vielen Fällen binnen Tagen
-behoben und unstable bietet außerdem immer die neueste für Debian paketierte
+behoben und Unstable bietet außerdem immer die neueste für Debian paketierte
Software.
</list>
-<p>Aber manchmal kann es günstiger sein, testing mitzuverfolgen als unstable.
+<p>Aber manchmal kann es günstiger sein, Testing mitzuverfolgen als unstable.
Der Autor dieser Dokumentation erlebte so etwas während dem Wechsel von gcc3
auf gcc4: Er versuchte, das Paket <package>labplot</package> auf einem Rechner
-zu installieren, der unstable folgte. Das gelang nicht, da nur einige der
+zu installieren, der Unstable folgte. Das gelang nicht, da nur einige der
Abhängigkeiten im Zuge des gcc-Übergangs bereits erfüllt waren, andere jedoch
-nicht. In testing ließ sich das Paket dagegen installieren, da die im Übergang
+nicht. In Testing ließ sich das Paket dagegen installieren, da die im Übergang
befindlichen Pakete noch nicht in dort angelangt waren.</p>
-<sect1>Hier ist die Rede davon, dass testing "kaputt" gehen kann. Was soll das
+<sect1>Hier ist die Rede davon, dass Testing "kaputt" gehen kann. Was soll das
heißen?
<p>Es kann vorkommen, dass sich ein Paket nicht mit den
@@ -174,54 +174,54 @@
<p>Wenn solche Dinge passieren, sagt man von einer Distribution, dass sie
(zumindest in Bezug auf dieses eine Paket) kaputt ist.</p>
-<sect1>Wie kann es sein, das testing monatelang kaputt ist? Würden die in
-unstable eingepflegten Fehlerkorrekturen nicht direkt in testing einfließen?
+<sect1>Wie kann es sein, dass Testing monatelang kaputt ist? Würden die in
+Unstable eingepflegten Fehlerkorrekturen nicht direkt in Testing einfließen?
-<p>Die Fehlerkorrekturen und Verbesserungen aus der Distribution unstable
-gelangen nur langsam nach einer bestimmten Anzahl von Tagen nach testing.
-Nehmen wir an, dieser Wert liegt bei zehn Tagen. Die Pakete in unstable
-gelangen erst nach testing, wenn dafür keine neuen veröffentlichungskritischen
+<p>Die Fehlerkorrekturen und Verbesserungen aus der Distribution Unstable
+gelangen nur langsam nach einer bestimmten Anzahl von Tagen nach Testing.
+Nehmen wir an, dieser Wert liegt bei zehn Tagen. Die Pakete in Unstable
+gelangen erst nach Testing, wenn dafür keine neuen veröffentlichungskritischen
Fehler mehr gemeldet werden. Wenn also ein veröffentlichungskritischer Fehler
-für das Paket vorliegt, wird es auch nicht nach zehn Tagen nach testing
+für das Paket vorliegt, wird es auch nicht nach zehn Tagen nach Testing
gelangen.</p>
<p>Die Idee ist folgende: wenn das Paket irgendwelche Fehler hat, dann würden
-diese von Benutzern entdeckt werden, die unstable verwenden und würden
-bereinigt, bevor das Paket nach testing kommt. Das hält testing für die meiste
+diese von Benutzern entdeckt werden, die Unstable verwenden und würden
+bereinigt, bevor das Paket nach Testing kommt. Das hält Testing für die meiste
Zeit in einem benutzbaren Zustand. Insgesamt ein brillantes Konzept. Allerdings
sind die Dinge nicht immer so einfach. Überdenken Sie folgende Situation:</p>
<p><list>
<item>Stellen Sie sich vor, Sie wären am Paket XYZ.dd interessiert.
- <item>Nehmen wir an, dass am 10. Juni die Version XYZ-3.6 in testing
+ <item>Nehmen wir an, dass am 10. Juni die Version XYZ-3.6 in Testing
ist und Version XYZ-3.7 in unstable.
- <item>Nach zehn Tagen wandert XYZ-3.7 von unstable nach testing.
- <item>Also haben am 20. Juni sowohl testing als auch unstable XYZ-3.7 in
+ <item>Nach zehn Tagen wandert XYZ-3.7 von Unstable nach Testing.
+ <item>Also haben am 20. Juni sowohl Testing als auch Unstable XYZ-3.7 in
ihren Repositories.
- <item>Sagen wir, ein Benutzer der testing-Distribution bemerkt, dass ein
+ <item>Sagen wir, ein Benutzer der Testing-Distribution bemerkt, dass ein
neues XYZ-Paket verfügbar ist und macht ein Update von XYT-3.6 zu
XYZ-3.7.
- <item>Nun entdeckt am 25. Juni jemand der testing oder unstable benutzt
- einen veröffentlichungskritischen Fehler im XYZ-3.7 und meldet diesen an
+ <item>Nun entdeckt am 25. Juni jemand der Testing oder Unstable benutzt,
+ einen veröffentlichungskritischen Fehler im XYZ-3.7 und meldet diesen an
das BTS.
<item>Der Betreuer von XYZ behebt den Fehler und lädt ein neues Paket
- nach unstable hoch, sagen wir am 30. Juni. Wir nehmen hierbei an, dass
+ nach Unstable hoch, sagen wir am 30. Juni. Wir nehmen hierbei an, dass
der Betreuer fünf Tage braucht, um den Fehler zu beheben und die neue
Version hochzuladen. Die Zahl von fünf Tagen sollte hier nicht falsch
verstanden werden. Es kann länger dauern oder auch nicht, in
Abhängigkeit von der Schwere des vorliegenden
veröffentlichungskritischen Fehlers.
<item>Die neue Version ist nun in unstable. Laut Plan soll XYZ-3.8
- daraufhin testing am 10. Juli erreichen.
+ daraufhin Testing am 10. Juli erreichen.
<item>Aber schon am 5. Juli entdeckt wieder jemand einen
veröffentlichungskritischen Fehler in XYZ-3.8.
- <item>Nehmen wir an, der Betreuen löst das Problem und lädt die neue
+ <item>Nehmen wir an, der Betreuer löst das Problem und lädt die neue
Version von XYZ nach fünf Tagen hoch.
- <item>Also ist am 10. Juli XYZ-3.7 in testing und XYZ-3.9 in unstable.
+ <item>Also ist am 10. Juli XYZ-3.7 in Testing und XYZ-3.9 in unstable.
<item>Die neue Version XYZ-3.9 soll nach dem neuen Zeitplan nun am 20.
- Juli in testing ankommen.
- <item>Nachdem Sie ja testing verwenden und XYZ-3.7 fehlerhaft ist,
+ Juli in Testing ankommen.
+ <item>Nachdem Sie ja Testing verwenden und XYZ-3.7 fehlerhaft ist,
könnten sie wahrscheinlich XYZ erst wieder nach dem 20. Juli benutzen.
Im Endeffekt hätten Sie dann rund einen Monat lang ein kaputtes Paket XYZ
gehabt.
@@ -230,7 +230,7 @@
<p>Die Angelegenheit kann noch weitaus komplizierter werden, wenn etwa XYZ von
vier anderen Paketen abhängt. Das kann dann zu einer monatelang nicht
-benutzbaren testing-Distribution führen. Das soeben vorgestellte Szenario ist
+benutzbaren Testing-Distribution führen. Das soeben vorgestellte Szenario ist
zwar konstruiert, kann aber im echten Leben tatsächlich vorkommen. Allerdings
geschieht das nur selten.
@@ -240,10 +240,10 @@
<p>Einer der Gründe, warum viele Leute Debian anderen Linux-Distributionen
vorziehen, ist der, dass es nur sehr wenig Verwaltungsaufwand erfordert. Diese
Leute wollen ein System, das einfach nur funktioniert. Im allgemeinen kann man
-sagen, dass stable nur sehr wenig Wartung bedarf, während testing und unstable
-nach fortwährender Pflege durch den Systemwerwalter verlangen. Wenn Sie stable
+sagen, dass Stable nur sehr wenig Wartung bedarf, während Testing und Unstable
+nach fortwährender Pflege durch den Systemverwalter verlangen. Wenn Sie Stable
verwenden, müssen Sie lediglich darauf achten, mit den Sicherheitsupdates
-Schritt zu halten. Wenn Sie testing oder unstable verwenden, ist es klug, ein
+Schritt zu halten. Wenn Sie Testing oder Unstable verwenden, ist es klug, ein
Auge auf neu entdeckte Fehler, Fehlerberichtigungen und neue Fähigkeiten in
den bereits installierten Paketen zu haben.</p>
@@ -270,26 +270,26 @@
testing = &testingreleasename;; unstable = sid
<item>Unstable wird immer sid genannte, unabhängig davon, ob eine
Veröffentlichung gemacht wurde, oder nicht.
- <item>Pakete wandern fortwährend von sid nach testing (beispielsweise
- &testingreleasename;). Aber Pakete in stable (beispielsweise &releasename;)
- bleiben immer diesselben, außer im Falle von Sicherheitsupdates.
- <item>Nach einer bestimmten Zeit wird testing eingefroren; wird aber
- weiterhin als testing bezeichnet. Von nun an gelangen keine Pakete
- von unstable nach testing mehr, es sei denn, um veröffentlichungskritische
+ <item>Pakete wandern fortwährend von sid nach Testing (beispielsweise
+ &testingreleasename;). Aber Pakete in Stable (beispielsweise &releasename;)
+ bleiben immer die selben, außer im Falle von Sicherheitsupdates.
+ <item>Nach einer bestimmten Zeit wird Testing eingefroren; wird aber
+ weiterhin als Testing bezeichnet. Von nun an gelangen keine Pakete
+ von Unstable nach Testing mehr, es sei denn, um veröffentlichungskritische
(RC) Fehler zu beheben.
- <item>Nachdem testing eingefroren wurde, müssen alle neu eingeführten
+ <item>Nachdem Testing eingefroren wurde, müssen alle neu eingeführten
Fehlerkorrekturen händisch durch die Mitglieder des Veröffentlichungs-Teams
überprüft werden. Das soll sicherstellen, dass sich keine ernsthaften Fehler
- in die eingefrorene testing-Veröffentlichung mehr einschleichen können.
- <item>Die RC-Fehler im eingefrorenen testing werden auf Null reduziert.
- <item>Das eingefrorene testing wird ohne RC-Fehler als neue stabile
+ in die eingefrorene Testing-Veröffentlichung mehr einschleichen können.
+ <item>Die RC-Fehler im eingefrorenen Testing werden auf Null reduziert.
+ <item>Das eingefrorene Testing wird ohne RC-Fehler als neue stabile
Veröffentlichung herausgegeben. In unserem Beispiel würde diese neue
Veröffentlichung &testingreleasename; genannt werden.
<item>Nun ist oldstable = &releasename;, stable = &testingreleasename;. Zu
- diesem Zeitpunkt entsprechen sich der Inhalt von stable und eingefrorenem
- testing.
- <item>Ein neues testing wird aus dem derzeitigen stable abgeleitet.
- <item>Pakete beginnen wieder aus sid nach testing herunterzukommen und die
+ diesem Zeitpunkt entsprechen sich der Inhalt von Stable und eingefrorenem
+ Testing.
+ <item>Ein neues Testing wird aus dem derzeitigen Stable abgeleitet.
+ <item>Pakete beginnen wieder aus sid nach Testing herunterzukommen und die
Debian-Gemeinschaft beginnt auf die nächste Veröffentlichung hinzuarbeiten.
</list>
@@ -309,7 +309,7 @@
<p>Sie können außerdem <prgn>lsb_release</prgn> abfragen (verfügbar über das
<package>lsb-release</package> Paket). Wenn Sie dieses Programm auf einem
-System mit unstable ausführen, erhalten Sie Folgendes:
+System mit Unstable ausführen, erhalten Sie Folgendes:
<example>
$ lsb_release -a
@@ -327,27 +327,27 @@
verwendet. So etwas wird häufig als apt-pinning bezeichnet. Solche Systeme
verwenden wahrscheinlich einen Mix aus unterschiedlichen Distributionen.
-<sect1>Augenblicklich verwende ich stable. Kann ich zu testing oder unstable
+<sect1>Augenblicklich verwende ich stable. Kann ich zu Testing oder Unstable
wechseln? Und wenn, wie?
-<p>Wenn Sie derzeitig stable einsetzen, dann wird in der Datei
+<p>Wenn Sie derzeitig Stable einsetzen, dann wird in der Datei
<file>/etc/apt/sources.list</file> das dritte Feld entweder &releasename; oder
stable sein. Diesen Eintrag müssen Sie passend zu der Distribution ändern, die
-Sie verwenden möchten. Wenn das testing ist, dann ändern Sie das dritte Feld von
-<file>/etc/apt/sources.list</file> in testing. Wenn Sie unstable verwenden
-wollen, dann tragen Sie in das dritte Feld unstable ein.
+Sie verwenden möchten. Wenn das Testing ist, dann ändern Sie das dritte Feld von
+<file>/etc/apt/sources.list</file> in Testing. Wenn Sie Unstable verwenden
+wollen, dann tragen Sie in das dritte Feld Unstable ein.
-<p>Gegenwärtig wird testing &testingreleasename; genannt. Wennn Sie das dritte
+<p>Gegenwärtig wird Testing &testingreleasename; genannt. Wennn Sie das dritte
Feld von <file>/etc/apt/sources.list</file> in &testingreleasename; ändern, dann
-werden Sie künftig testing verwenden. Aber auch wenn &testingreleasename; stable
+werden Sie künftig Testing verwenden. Aber auch wenn &testingreleasename; stable
wird, werden Sie weiterhin &testingreleasename; haben.</p>
<p>Unstable wird immer sid genannt. Wenn Sie also das dritte Feld von
-<file>/etc/apt/sources.list</file> in sid ändern, werden Sie stets unstable folgen.
+<file>/etc/apt/sources.list</file> in sid ändern, werden Sie stets Unstable folgen.
-<p>Gegenwärtig bietet Debian Sicherheitsupdates für testing aber nicht für
-unstable an, da Fehlerkorrekturen für unstable direkt im Hauptarchiv vorgenommen
-werden. Wenn Sie also unstable benutzen, sollten Sie sicherstellen, dass Sie die
+<p>Gegenwärtig bietet Debian Sicherheitsupdates für Testing aber nicht für
+Unstable an, da Fehlerkorrekturen für Unstable direkt im Hauptarchiv vorgenommen
+werden. Wenn Sie also Unstable benutzen, sollten Sie sicherstellen, dass Sie die
Zeilen in <file>/etc/apt/sources.list</file> entfernen, die sich auf
Sicherheitsupdates beziehen.
@@ -357,12 +357,12 @@
Veröffentlichungshinweise enthalten möglicherweise Informationen über die Art,
wie Sie das Upgrade vornehmen sollten.
-<p>Dennoch können Sie nachdem sich die obigen Veränderungen vorgenommen haben,
+<p>Dennoch können Sie, nachdem Sie die obigen Veränderungen vorgenommen haben,
<prgn>aptitude update</prgn> laufen lassen und dann die Pakete installieren,
die Sie haben möchten. Beachten Sie, dass das Installieren eines Pakets aus
einer anderen Distribution möglicherweise automatisch gleich Ihr halbes System
einem Upgrade unterzieht. Wenn Sie einzelne Pakete installieren, haben Sie zum
-Schluß ein System, auf denen eine Mischung verschiedener Distributionen läuft.
+Schluss ein System, auf denen eine Mischung verschiedener Distributionen läuft.
<p>In bestimmten Situationen ist es daher wahrscheinlich das Beste, ein volles
Upgrade auf die neue Distribution zu machen, indem man <prgn>apt-get
@@ -370,14 +370,14 @@
full-upgrade</prgn> benutzt. Lesen Sie die Handbuchseiten von apt und aptitude
für weiterführende Informationen.
-<sect1>Im Augenblick verwende ich testing (&testingreleasename;). Was wird
+<sect1>Im Augenblick verwende ich Testing (&testingreleasename;). Was wird
passieren, wenn eine neue Veröffentlichung herauskommt? Werde ich weiterhin
-testing haben oder wird auf meinem Rechner die neue stabile Distribution
+Testing haben oder wird auf meinem Rechner die neue stabile Distribution
laufen?
<p>Das hängt von den Einträgen in der Datei <file>/etc/apt/sources.list</file>
-ab. Wenn Sie gegenwärtig testing mitverfolgen, sollt diese Einträge in etwa so
-aussehen:
+ab. Wenn Sie gegenwärtig Testing mitverfolgen, sollten diese Einträge in etwa
+so aussehen:
<example>
deb http://ftp.us.debian.org/debian/ testing main
@@ -390,14 +390,14 @@
</example>
<p>Wenn das dritte Feld in <file>/etc/apt/sources.list</file> 'testing' ist,
-dann werden Sie auch nach der Veröffentlichung noch testing haben. Nachdem
+dann werden Sie auch nach der Veröffentlichung noch Testing haben. Nachdem
&testingreleasename; veröffentlicht wurde, werden Sie eine neue
Debian-Distribution mit einem anderen Codenamen laufen haben. Am Anfang werden
die Veränderungen nicht auffällig sein. Das wird sich aber ändern, sobald neue
-Pakete von unstable in die testing-Distribution kommen.</p>
+Pakete von Unstable in die Testing-Distribution kommen.</p>
<p>Wenn aber das dritte Feld '&testingreleasename;' enthält, dann werden Sie
-künftig stable installiert haben, weil &testingreleasename; dann die neue
+künftig Stable installiert haben, weil &testingreleasename; dann die neue
stabile Veröffentlichung sein wird.</p>
<sect1>Ich bin noch immer verwirrt. Was sagten Sie, solle ich installieren?
@@ -476,7 +476,7 @@
der Paketwerkzeuge zu machen, da Sie am Ende möglicherweise mit einem
unbrauchbaren System dastehen.
-<p>Wenn sich all Ihre Benutzerdaten (beispielsweise <file>/home</file>) auf
+<p>Wenn sich alle Ihre Benutzerdaten (beispielsweise <file>/home</file>) auf
einer gesonderten Partition befinden, ist der Umstieg auf Debian ziemlich
einfach. Sie müssen das Installationssystem lediglich anweisen, diese
Partition bei der Neuinstallation einzubinden (aber nicht zu formatieren).
16c16
< <sect>Welche Debian-Distribution (Stable/Testing/Unstable) ist geeignet für
---
> <sect>Welche Debian-Distribution (stable/testing/unstable) is geeignet für
34c34
< zutrauen, können Sie mit wenig Aufwand zum etwas moderneren Unstable
---
> zutrauen, können Sie mit wenig Aufwand zum etwas moderneren unstable
44c44
< Internet erreichbar ist, sollten Sie Stable installieren. Das ist bei weitem
---
> Internet erreichbar ist, sollten Sie stable installieren. Das ist bei weitem
52c52
< <sect1>Sie haben mir empfohlen, Stable zu installieren. Allerdings wird unter
---
> <sect1>Sie haben mir empfohlen, stable zu installieren. Allerdings wird unter
58,61c58,61
< Hardware sollte gut unter Stable funktionieren. Wenn Sie aber bestimmte, sehr
< neue Hardware haben, kann es sein, dass diese nicht unter Stable funktioniert.
< Sollte das der Fall sein, möchten Sie vielleicht zu Unstable upgraden
< beziehungsweise Unstable installieren.</p>
---
> Hardware sollte gut unter stable funktionieren. Wenn Sie aber bestimmte, sehr
> neue Hardware haben, kann es sein, dass diese nicht unter stable funktioniert.
> Sollte das der Fall sein, möchten Sie vielleicht zu unstable upgraden
> beziehungsweise unstable installieren.</p>
86c86
< Pakete in Unstable nicht ausführlich getestet und haben möglicherweise
---
> Pakete in unstable nicht ausführlich getestet und haben möglicherweise
89c89
< <p>Andererseits enthält Stable zwar alte Paketversionen, diese sind jedoch
---
> <p>Andererseits enthält stable zwar alte Paketversionen, diese sind jedoch
93c93
< <p>Die Pakete in Testing stellen den Mittelweg zwischen diesen beiden Extremen
---
> <p>Die Pakete in testing stellen den Mittelweg zwischen diesen beiden Extremen
100c100
< <p>Da könnten Sie recht haben. Das Alter der Pakete in Stable hängt davon ab,
---
> <p>Da könnten Sie recht haben. Das Alter der Pakete in stable hängt davon ab,
103c103
< liegen, kann es sein, dass Sie den Eindruck gewinnen, dass Stable alte Pakete
---
> liegen, kann es sein, dass Sie den Eindruck gewinnen, dass stable alte Pakete
110c110
< <p>Umgekehrt können Pakete in Testing und Unstable versteckte Fehler,
---
> <p>Umgekehrt können Pakete in testing und unstable versteckte Fehler,
112c112
< Testing und Unstable funktionieren möglicherweise nicht wie beabsichtigt. Für
---
> testing und unstable funktionieren möglicherweise nicht wie beabsichtigt. Für
126c126
< "möglich". Sie sollten Sich also sicher sein, wenn sie planen Unstable zu
---
> "möglich". Sie sollten Sich also sicher sein, wenn sie planen unstable zu
131c131
< es möglich sein, von Unstable zu Testing und von Testing dann zu Stable zu
---
> es möglich sein, von unstable zu testing und von testing dann zu stable zu
136c136
< <sect1>Sollte man Testing oder Unstable installieren?
---
> <sect1>Sollte man testing oder unstable installieren?
140c140
< sich zwischen Testing und Stable zu entscheiden. Die Sache ist die:</p>
---
> sich zwischen testing und stable zu entscheiden. Die Sache ist die:</p>
150c150
< <item>In Unstable ändert sich sehr viel und es kann daher auch jederzeit
---
> <item>In unstable ändert sich sehr viel und es kann daher auch jederzeit
152c152
< behoben und Unstable bietet außerdem immer die neueste für Debian paketierte
---
> behoben und unstable bietet außerdem immer die neueste für Debian paketierte
157c157
< <p>Aber manchmal kann es günstiger sein, Testing mitzuverfolgen als unstable.
---
> <p>Aber manchmal kann es günstiger sein, testing mitzuverfolgen als unstable.
160c160
< zu installieren, der Unstable folgte. Das gelang nicht, da nur einige der
---
> zu installieren, der unstable folgte. Das gelang nicht, da nur einige der
162c162
< nicht. In Testing ließ sich das Paket dagegen installieren, da die im Übergang
---
> nicht. In testing ließ sich das Paket dagegen installieren, da die im Übergang
165c165
< <sect1>Hier ist die Rede davon, dass Testing "kaputt" gehen kann. Was soll das
---
> <sect1>Hier ist die Rede davon, dass testing "kaputt" gehen kann. Was soll das
177,178c177,178
< <sect1>Wie kann es sein, dass Testing monatelang kaputt ist? Würden die in
< Unstable eingepflegten Fehlerkorrekturen nicht direkt in Testing einfließen?
---
> <sect1>Wie kann es sein, das testing monatelang kaputt ist? Würden die in
> unstable eingepflegten Fehlerkorrekturen nicht direkt in testing einfließen?
180,183c180,183
< <p>Die Fehlerkorrekturen und Verbesserungen aus der Distribution Unstable
< gelangen nur langsam nach einer bestimmten Anzahl von Tagen nach Testing.
< Nehmen wir an, dieser Wert liegt bei zehn Tagen. Die Pakete in Unstable
< gelangen erst nach Testing, wenn dafür keine neuen veröffentlichungskritischen
---
> <p>Die Fehlerkorrekturen und Verbesserungen aus der Distribution unstable
> gelangen nur langsam nach einer bestimmten Anzahl von Tagen nach testing.
> Nehmen wir an, dieser Wert liegt bei zehn Tagen. Die Pakete in unstable
> gelangen erst nach testing, wenn dafür keine neuen veröffentlichungskritischen
185c185
< für das Paket vorliegt, wird es auch nicht nach zehn Tagen nach Testing
---
> für das Paket vorliegt, wird es auch nicht nach zehn Tagen nach testing
189,190c189,190
< diese von Benutzern entdeckt werden, die Unstable verwenden und würden
< bereinigt, bevor das Paket nach Testing kommt. Das hält Testing für die meiste
---
> diese von Benutzern entdeckt werden, die unstable verwenden und würden
> bereinigt, bevor das Paket nach testing kommt. Das hält testing für die meiste
197c197
< <item>Nehmen wir an, dass am 10. Juni die Version XYZ-3.6 in Testing
---
> <item>Nehmen wir an, dass am 10. Juni die Version XYZ-3.6 in testing
199,200c199,200
< <item>Nach zehn Tagen wandert XYZ-3.7 von Unstable nach Testing.
< <item>Also haben am 20. Juni sowohl Testing als auch Unstable XYZ-3.7 in
---
> <item>Nach zehn Tagen wandert XYZ-3.7 von unstable nach testing.
> <item>Also haben am 20. Juni sowohl testing als auch unstable XYZ-3.7 in
202c202
< <item>Sagen wir, ein Benutzer der Testing-Distribution bemerkt, dass ein
---
> <item>Sagen wir, ein Benutzer der testing-Distribution bemerkt, dass ein
205,206c205,206
< <item>Nun entdeckt am 25. Juni jemand der Testing oder Unstable benutzt,
< einen veröffentlichungskritischen Fehler im XYZ-3.7 und meldet diesen an
---
> <item>Nun entdeckt am 25. Juni jemand der testing oder unstable benutzt
> einen veröffentlichungskritischen Fehler im XYZ-3.7 und meldet diesen an
209c209
< nach Unstable hoch, sagen wir am 30. Juni. Wir nehmen hierbei an, dass
---
> nach unstable hoch, sagen wir am 30. Juni. Wir nehmen hierbei an, dass
216c216
< daraufhin Testing am 10. Juli erreichen.
---
> daraufhin testing am 10. Juli erreichen.
219c219
< <item>Nehmen wir an, der Betreuer löst das Problem und lädt die neue
---
> <item>Nehmen wir an, der Betreuen löst das Problem und lädt die neue
221c221
< <item>Also ist am 10. Juli XYZ-3.7 in Testing und XYZ-3.9 in unstable.
---
> <item>Also ist am 10. Juli XYZ-3.7 in testing und XYZ-3.9 in unstable.
223,224c223,224
< Juli in Testing ankommen.
< <item>Nachdem Sie ja Testing verwenden und XYZ-3.7 fehlerhaft ist,
---
> Juli in testing ankommen.
> <item>Nachdem Sie ja testing verwenden und XYZ-3.7 fehlerhaft ist,
233c233
< benutzbaren Testing-Distribution führen. Das soeben vorgestellte Szenario ist
---
> benutzbaren testing-Distribution führen. Das soeben vorgestellte Szenario ist
243,244c243,244
< sagen, dass Stable nur sehr wenig Wartung bedarf, während Testing und Unstable
< nach fortwährender Pflege durch den Systemverwalter verlangen. Wenn Sie Stable
---
> sagen, dass stable nur sehr wenig Wartung bedarf, während testing und unstable
> nach fortwährender Pflege durch den Systemwerwalter verlangen. Wenn Sie stable
246c246
< Schritt zu halten. Wenn Sie Testing oder Unstable verwenden, ist es klug, ein
---
> Schritt zu halten. Wenn Sie testing oder unstable verwenden, ist es klug, ein
273,278c273,278
< <item>Pakete wandern fortwährend von sid nach Testing (beispielsweise
< &testingreleasename;). Aber Pakete in Stable (beispielsweise &releasename;)
< bleiben immer die selben, außer im Falle von Sicherheitsupdates.
< <item>Nach einer bestimmten Zeit wird Testing eingefroren; wird aber
< weiterhin als Testing bezeichnet. Von nun an gelangen keine Pakete
< von Unstable nach Testing mehr, es sei denn, um veröffentlichungskritische
---
> <item>Pakete wandern fortwährend von sid nach testing (beispielsweise
> &testingreleasename;). Aber Pakete in stable (beispielsweise &releasename;)
> bleiben immer diesselben, außer im Falle von Sicherheitsupdates.
> <item>Nach einer bestimmten Zeit wird testing eingefroren; wird aber
> weiterhin als testing bezeichnet. Von nun an gelangen keine Pakete
> von unstable nach testing mehr, es sei denn, um veröffentlichungskritische
280c280
< <item>Nachdem Testing eingefroren wurde, müssen alle neu eingeführten
---
> <item>Nachdem testing eingefroren wurde, müssen alle neu eingeführten
283,285c283,285
< in die eingefrorene Testing-Veröffentlichung mehr einschleichen können.
< <item>Die RC-Fehler im eingefrorenen Testing werden auf Null reduziert.
< <item>Das eingefrorene Testing wird ohne RC-Fehler als neue stabile
---
> in die eingefrorene testing-Veröffentlichung mehr einschleichen können.
> <item>Die RC-Fehler im eingefrorenen testing werden auf Null reduziert.
> <item>Das eingefrorene testing wird ohne RC-Fehler als neue stabile
289,292c289,292
< diesem Zeitpunkt entsprechen sich der Inhalt von Stable und eingefrorenem
< Testing.
< <item>Ein neues Testing wird aus dem derzeitigen Stable abgeleitet.
< <item>Pakete beginnen wieder aus sid nach Testing herunterzukommen und die
---
> diesem Zeitpunkt entsprechen sich der Inhalt von stable und eingefrorenem
> testing.
> <item>Ein neues testing wird aus dem derzeitigen stable abgeleitet.
> <item>Pakete beginnen wieder aus sid nach testing herunterzukommen und die
312c312
< System mit Unstable ausführen, erhalten Sie Folgendes:
---
> System mit unstable ausführen, erhalten Sie Folgendes:
330c330
< <sect1>Augenblicklich verwende ich stable. Kann ich zu Testing oder Unstable
---
> <sect1>Augenblicklich verwende ich stable. Kann ich zu testing oder unstable
333c333
< <p>Wenn Sie derzeitig Stable einsetzen, dann wird in der Datei
---
> <p>Wenn Sie derzeitig stable einsetzen, dann wird in der Datei
336,338c336,338
< Sie verwenden möchten. Wenn das Testing ist, dann ändern Sie das dritte Feld von
< <file>/etc/apt/sources.list</file> in Testing. Wenn Sie Unstable verwenden
< wollen, dann tragen Sie in das dritte Feld Unstable ein.
---
> Sie verwenden möchten. Wenn das testing ist, dann ändern Sie das dritte Feld von
> <file>/etc/apt/sources.list</file> in testing. Wenn Sie unstable verwenden
> wollen, dann tragen Sie in das dritte Feld unstable ein.
340c340
< <p>Gegenwärtig wird Testing &testingreleasename; genannt. Wennn Sie das dritte
---
> <p>Gegenwärtig wird testing &testingreleasename; genannt. Wennn Sie das dritte
342c342
< werden Sie künftig Testing verwenden. Aber auch wenn &testingreleasename; stable
---
> werden Sie künftig testing verwenden. Aber auch wenn &testingreleasename; stable
346c346
< <file>/etc/apt/sources.list</file> in sid ändern, werden Sie stets Unstable folgen.
---
> <file>/etc/apt/sources.list</file> in sid ändern, werden Sie stets unstable folgen.
348,350c348,350
< <p>Gegenwärtig bietet Debian Sicherheitsupdates für Testing aber nicht für
< Unstable an, da Fehlerkorrekturen für Unstable direkt im Hauptarchiv vorgenommen
< werden. Wenn Sie also Unstable benutzen, sollten Sie sicherstellen, dass Sie die
---
> <p>Gegenwärtig bietet Debian Sicherheitsupdates für testing aber nicht für
> unstable an, da Fehlerkorrekturen für unstable direkt im Hauptarchiv vorgenommen
> werden. Wenn Sie also unstable benutzen, sollten Sie sicherstellen, dass Sie die
360c360
< <p>Dennoch können Sie, nachdem Sie die obigen Veränderungen vorgenommen haben,
---
> <p>Dennoch können Sie nachdem sich die obigen Veränderungen vorgenommen haben,
365c365
< Schluss ein System, auf denen eine Mischung verschiedener Distributionen läuft.
---
> Schluß ein System, auf denen eine Mischung verschiedener Distributionen läuft.
373c373
< <sect1>Im Augenblick verwende ich Testing (&testingreleasename;). Was wird
---
> <sect1>Im Augenblick verwende ich testing (&testingreleasename;). Was wird
375c375
< Testing haben oder wird auf meinem Rechner die neue stabile Distribution
---
> testing haben oder wird auf meinem Rechner die neue stabile Distribution
379,380c379,380
< ab. Wenn Sie gegenwärtig Testing mitverfolgen, sollten diese Einträge in etwa
< so aussehen:
---
> ab. Wenn Sie gegenwärtig testing mitverfolgen, sollt diese Einträge in etwa so
> aussehen:
393c393
< dann werden Sie auch nach der Veröffentlichung noch Testing haben. Nachdem
---
> dann werden Sie auch nach der Veröffentlichung noch testing haben. Nachdem
397c397
< Pakete von Unstable in die Testing-Distribution kommen.</p>
---
> Pakete von unstable in die testing-Distribution kommen.</p>
400c400
< künftig Stable installiert haben, weil &testingreleasename; dann die neue
---
> künftig stable installiert haben, weil &testingreleasename; dann die neue
479c479
< <p>Wenn sich alle Ihre Benutzerdaten (beispielsweise <file>/home</file>) auf
---
> <p>Wenn sich all Ihre Benutzerdaten (beispielsweise <file>/home</file>) auf
Reply to: