debian-faq/de/ diffs: choosing.sgml II
Hallo Liste,
sorry; noch eine Kleinigkeit mit rechts tretender Zeile gefunden.
Gruß,
Martin
Index: choosing.sgml
===================================================================
--- choosing.sgml (Revision 5332)
+++ 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
@@ -174,7 +174,7 @@
<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
+<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
@@ -202,9 +202,9 @@
<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
- das BTS.
+ <item>Nun entdeckt am 25. Juni jemand der testing oder unstable
+ benutzt, einen veröffentlichungskritischen Fehler im XYZ-3.7 und meldet
+ diesen an 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
der Betreuer fünf Tage braucht, um den Fehler zu beheben und die neue
@@ -216,7 +216,7 @@
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>Die neue Version XYZ-3.9 soll nach dem neuen Zeitplan nun am 20.
@@ -241,7 +241,7 @@
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
+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
Auge auf neu entdeckte Fehler, Fehlerberichtigungen und neue Fähigkeiten in
@@ -272,24 +272,24 @@
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
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
+ <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
+ <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>
@@ -313,7 +313,8 @@
<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
@@ -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
@@ -376,8 +377,8 @@
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
@@ -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).
Reply to: