Moin,
On Sun, Apr 16, 2006 at 12:54:34PM +0200, Andre Appel wrote:
> Die f*r Debian paketierte Software ist in einem von zahlreichen
> Verzeichnisb*umen auf jedem Debian Spiegel verf*gbar.
s/Debian Spiegel/Debian-Spiegel/
> Das dists Verzeichnis ist die Abk*rzung f*r "distributions" und ist der
s/dists Verzeichnis/dists-Verzeichnis/ ggf. das »dists« in Anführungszeichen?
s/"distributions"/»distributions«/
> *bliche Weg, um auf die zur Zeit verf*gbaren Debian Distributionen (und
s/Debian Distributionen/Debian-Distributionen/
> deren Vorg*nger) zuzugreifen.
>
> Das pool Verzeichnis enth*lt die eigentlichen Pakete, siehe dazu auch .
s/pool Verzeichnis/pool-Verzeichnis/
(bitte analog alle weiteren Bindestriche durchgehen ...)
> Es gibt zahlreiche zus*tzliche Verzeichnisse: /tools/: enth*lt DOS
> Werkzeuge zum Erstellen von boot-Disketten, zur Paritionierung, zum
s/Paritionierung/Partionierung/
> Packen/Entpacken von Dateien und um Linux zu booten /doc/: enth*lt die
> grundlegende Debian Dokumentation, wie z.B. die FAQ, die Anleitung f*r das
> bug-reporting System, etc. /indices/: enth*lt die Dateien der
s/bug-reporting System/Fehler-Melde-System/
s/, etc./ usw./
> Paketbetreuer und Teile der Konfigurationen der Archiv-Skipte (sog.
> "override files") /project/: enth*lt haupts*chlich f*r Entwickler
s/"override files"/????/
> relevante Dinge, wie z.B.: project/experimental/: Dieses Verzeichnes
s/Verzeichnes/Verzeichnis/ ggf. ispell/aspell einsetzen
> ent*lt Pakete und Tools welche sich noch in der Entwicklung befinden und
s/Tools/Werkzeuge/
> meist noch Alpha-Status haben. Benutzer sollten keine der dort
> befindlichen Pakete nutzen, da diese selbst f*r erfahrene Nutzer
s/Nutzer/Benutzer/
> gef*hrlich sein k*nnen. Wie viele Debian Distributionen befinden sich in
> dem dists Verzeichnis?
>
> Es gibt 3 Distributionen, die "stable", die "testing" und die "unstable"
s/3/drei/
s/"stable"/»Stable«/ die anderen analog
> Distribution. Die "testing" Distribution kann zeitweise "frozen" sein (see
> ). Was haben all diese Namen wie slink, potato, etc. zu bedeuten?
s/slink/Slink/ Eigennamen (auch der Distributionen) alle groß
> Dabei handelt es sich einfach um "Codenamen". Jeden Debian Distribution,
Warum Codenamen in Anführungsstrichen?
s/Jeden Debian Distribution/Jede Debian-Distribution/
> die sich noch in der Entwicklung befindet, besitzt keine Versionsnummer
> aber einen Codenamen. Der Zweck dieser Codenamen ist es, das Spiegeln von
> Debian Distributionen zu vereinfachen (wenn ein echtes Verzeichnis wie
> unstable pl*tzlich in stable umbenannt werden w*rde, w*rden eine Menge an
> Daten sinnloserweise erneut heruntergeladen werden).
>
> Zur Zeit ist stable ein symbolischer link auf &releasename; (z.B. &debian;
Achtung: Hier wird vom Link gesprochen, daher bleibt stable klein!!
> &release;) und testing ein symbolischer Link auf &testingreleasename; Dies
> bedeutet, dass &releasename; die derzeitige stable-Distribution und
Und hier wieder groß: s/stable-Distribution/Stable-Distribution/
> &testingreleasename; die derzeitige testing-Distribution ist.
>
> Unstable wiederum ist ein permanenter symbolischer link auf sid, da sid
> immer die unstable Distribution bleiben wird (siehe dazu ). Welche
> Codenamen wurden in der Vergangenheit verwendet?
>
> Andere, bereits verwendete Codename sind: buzz f*r Release 1.1, rex f*r
> Release 1.2, bo f*r Releases 1.3.x, hamm f*r Release 2.0, slink f*r
> Release 2.1, potato f*r Release 2.2 and woody f*r Release 3.0. Woher
> stammen all diese Codenamen?
>
> Bis jetzt wurden immer Charaktere des Films "Toy Story" von Pixar zur
> Namensgebung herangezogen: buzz (Buzz Lightyear) war der Raumfahrer, rex
> war der Tyrannosaurus, bo (Bo Peep) war das M*dchen, welches die Schafe
> geh*tet hat, hamm war das Sparschwein, slink (Slinky Dog (R)) war der
> Spielzeughund, potato war, logischerweise, Mr. Potato (R), woody war der
> Cowboy, sarge war der Sergeant der gr*nen Plastiksoldaten, etch war die
> Spielzeugtafel (Etch-a-Sketch (R)). sid war der Junge von Nebenan, welcher
> immer die Spielzeuge kaputt machte. Was ist mit "sid"?
>
> Sid oder unstable ist der Ort wo die meisten Pakete als erstes hochgeladen
> werden. Es wird nie direkt ver*ffentlicht werden, da zu ver*ffentlichende
> Pakete erst in testing eingef*gt werden, um dann sp*ter in stable
> *bernommen zu werden. Sid enth*lt Pakete f*r bereits ver*ffentlichte und
> unver*ffentlichte Architekturen.
>
> Der Name "sid" kommt urspr*nglich aus dem Animationsfilm "Toy Story": Sid
> war der Junge von Nebenan der immer Spielzeuge zerst*rte :-)
>
> Als es damals Sid noch nicht gab, besa* die Organisation der FTP-Sites
> eine gro*e Schwachstelle: Es galt die Annahme, dass beim Erstellen einer
> Architektur im derzeitigen Unstable die Ver*ffentlichung erfolgte, sobald
> diese Distribution das neue Stable wurde. Allerdings ist dies f*r viele
> Architekturen nicht der Fall, mit dem Ergebnis das diese Verzeichniss zum
> Release-Termin verschoben werden mussten. Dies war extrem unpraktisch, da
> das Verschieben sehr viel Bandbreite verbrauchte.
>
> Die Archiv-Administratoren umgingen dieses Problem jahrelang in dem sie
> Programme f*r unver*ffentlichte Architekturen in einem speziellem
> Verzeichnis namens "sid" lagerten. F*r diese unver*ffentlichten
> Architekturen wurde, sobald sie dann ver*ffentlicht wurden, ein link vom
s/link/Link/
> derzeitigen stable auf sid gesetzt. Ab diesem Zeitpunkt wurden sie ganz
> normal innerhalb des "unstable" Zweiges erstellt. Diese Anordnung
> verwirrte allerdings die Benutzer.
>
> Mit der Einf*hrung von Paket-Pools (siehe auch ) wurden bin*re Pakete an
> den vorschriftsm**igen Orten des Pools gespeichert, unabh*ngig von der
> Distribution. Dadurch wird verhindert, dass mit der Ver*ffentlichung einer
> Distribution gro*e Mengen an Bandbreite verbraucht werden (allerdings wird
> sukzessiv Bandbreite w*hrend der Entwicklung verbraucht). Was enth*lt das
> "stable" Verzeichnis?
>
> stable/main/: Dieses Verzeichnis enth*lt die Pakete, welche zur Zeit den
> neusten Release des &debian; Systems darstellen.
Hier würde ich statt Release Veröffentlichung schreiben
> All diese Pakete entsprechen den und sind damit frei benutzbar und
den wen?
> verbreitbar. stable/non-free/: Dieses Verzeichnis enth*lt Pakete welche
> auf die eine oder andere Art durch Copyright Bedingungen eingeschr*nkt
> sind
s/sind/sind./
> Einige Pakete z.B. haben Lizenzbedingungen welche die kommerzielle Nutzung
> verbieten. Wiederum andere k*nnen weitergegeben werden, sind aber
> eigentlich Shareware und keine Freeware. Die Lizenzbedingungen jedes
Steht der Ausdruck Freeware im Original?
> dieser Pakete m*ssen genau gelesen und wahrscheinlich verhandelt werden,
> bevor eines der Pakete verteilt werden darf, z.B. auf einer CD-ROM.
> stable/contrib/: Dieses Verzeichnis enth*lt Pakete welche DFSG-frei und
s/DFSG-frei/frei im Sinne der DFSG/
> frei verteilbar sind, aber von Paketen abh*ngen, welche nicht frei und
> deshalb nur in non-free zu finden sind. Was enth*lt das "testing"
> Verzeichnis?
>
> Pakete landen im testing Verzeichnis nachdem sie zu einem gewissen Grad in
> unstable getestet wurden.
Kommasetzung bin ich nicht so optimal, aber mein Eindruck ist, das
öfters mal welche fehlen, z.B. hier nach »Verzeichnis«.
> Diese Pakete m*ssen identisch f*r alle Architekturen vorliegen auf denen
> sie gebaut wurden. Es darf auch keine Abh*ngigkeiten geben, welche sie
> uninstallierbar machen w*rden. Desweiteren m*ssen sie weniger
> release-kritische Fehler aufweisen als die aktuelle Version in testing.
> Auf diese Art erhofft man sich, dass "testing" immer nahe daran ist ein
> Release Kandidat zu werden.
>
> Weitere Informationen *ber den Status von "testing" und *ber die einzelnen
> Pakete sind verf*gbar unter Wie erh*lt "testing" den "frozen" Status?
sind unter ... verfügbar.
> Sobald die "testing" Distribution weit genug fortgeschritten ist erh*lt
> sie den "frozen" Status durch den Release- Manager. Die normalen
s/Release- Manager/Release-Manager/
> Verz*gerungspausen der Aufnahme von Paketen nach "testing" werden
> verl*ngert, um so weniger neue Bugs von "unstable" nach "testing" zu
s/Bugs/Fehler/
> lassen.
>
> Nach einiger Zeit wird die "testing" Distribution dann wirklich "frozen",
> also eingefroren. Dies bedeutet, dass alle neuen Pakete die nach "testing"
> sollen zur*ckgehalten werden, au*er sie beheben release-kritische Fehler.
Der Satz ist schief. Ok, wenn ich nach »sollen« ein Komma setze,
ergibt er Sinn.
> Die "testing" Distribution kann auch in diesem Zustand w*hrend der
> "Testzyklen" verweilen, wenn der Release kurz bevor steht.
Auch hier würde ich »Release« übersetzen (woanders überings durchaus
auch).
> Alle Fehler in der "testing" Distribution die ein Paket an der Freigabe
> hindern oder den ganzen Release verhindern werden mitprotokoliert. Um mehr
s/mitprotokoliert/mitprotokolliert./
> Details zu erfahren, siehe auch .
>
> Sobald die Anzahl der Bugs sich einem akzeptablen Wert n*hert wird die
s/Bugs/Fehler/
> "testing" Distribution als "stable" deklariert und versehen mit einer
> Versionsnummer freigegeben.
>
> Mit jedem neuen Release ist die vorhergegangene "stable" Distribution
> *berholt und wird in das Archiv verschoben. F*r weitere Informationen,
> siehe auch . Was enth*lt das "unstable" Verzeichnis?
>
> Das "unstable" Verzeichnis enth*lt eine Momentaufnahme des derzeitigen
> Entwicklungsystems. Benutzer d*rfen dieses gerne benutzen und testen. Man
s/Entwicklungsystems/Entwicklungssystems/
> sei aber gewarnt, dass es keine Garantie einer Betriebsf*higkeit gibt. Der
Was ist das englische Originalwort für »Betriebsfähigkeit« ?
> Vorteil von "unstable" liegt darin, dass alle Pakete up-to-date sind. Wenn
s/up-to-date/aktuell/
> allerdings etwas kaputt geht: Pech gehabt :)
>
> Nat*rlich gibt es in "unstable" genauso die Verzeichnisse "main",
> "contrib" und "non-free", die wie in "stable" beschrieben sortiert sind.
> Was haben die ganzen Verzeichnisse in dists/stable/main zu bedeuten?
>
> In jedem Hauptverzeichnisdists/stable/main,dists/stable/contrib,
s/Hauptverzeichnisdists\/stable\/main/Hauptverzeichnisdists \/stable\/main/
> dists/stable/non-free, und dists/unstable/main/, etc. gibt es 3
> Zusammenstellungen von Unterverzeichnissen, welche Index-Dateien
> enthalten.
>
> Da sind zu einem die binary-irgendwas Verzeichnisse welche die
> Index-Dateien f*r die Binary-Pakete f*r jede verf*gbare
> Computerarchitektur enthalten, z.B. /binary-i386/ f*r Pakete welche auf
s/Binary-Pakete/Binärpakete/
> der Intel x86 Architektur laufen oder /binary-sparc/ f*r Pakete welche auf
> Sun SPARCStationen laufen.
>
> Die vollst*ndige Liste der verf*gbaren Archtitekturen f*r jeden Release
s/Archtitekturen/Architekturen/
> ist unter verf*gbar. F*r den derzeit aktuellen Release siehe auch .
>
> Die Index Dateien in binary-* sind so genannte Pakete(.gz) und enthalten
> eine Zusammenfassung jedes Binary-Pakets welches in dieser Distribution zu
> finden ist. Die eigentlichen Binary-Pakete (f*r /woody/ und folgende
> Releases) liegen direkt in /pool/ directory.
>
> Desweiteren existiert ein Unterverzeichnis "source/", welches
> Index-Dateien f*r die Quellpakete jeder Distribution beinhaltet. Die
> Index-Datei daf*r hei*t Sources(.gz).
>
> Zu guter Letzt existiert einen Satz von Unterverzeichnissen welche die f*r
> das Installationsystem notwendigen Index-Dateien beinhalten. F*r woody
s/Installationsystem/Installationssystem/
> hei*en diese disks-architecture; f*r sarge
> debian-installer/binary-architecture. Wo befindet sich der Quellcode?
>
> Der gesamte Quellcode f*r alles in Debian ist verf*gbar. Es ist sogar so,
> dass die Lizenzbedingungen der meisten Programme des Systems es verlangen
> das der Quellcode zusammen mit dem eigentlichen Programm ausgeliefert wird
> oder wenigstens zur Verf*gung steht.
>
> Der Quellcode wird *ber das pool Verzeichnis (see ) verteilt, zusammen mit
s/see/siehe/
> den architekturspezifischen Bin*rverzeichnissen. Um den Quellcode zu
> erhalten, ohne sich um die FTP-Archiv Verzeichnisstruktur k*mmern zu
> m*ssen, kann man z.B. apt-get source paketname verwenden.
>
> Einige Pakete werden auf Grund von Einschr*nkungen in ihren Lizenzen nur
> als Quellcode verteilt. pinez.B ist ein solches Paket, siehe auch .
s/pinez.B/pine z.B/
>
> F*r Pakete in "contrib" und "non-free" kann der Quellcode verf*gbar sein,
> muss aber nicht. Was befindet sich im pool directory?
>
> Pakete werden in einem gro*en "Pool" gelagert, strukturiert nach dem Namen
> des Quellpaketes. Um dies zu verwalten ist der Pool unterteilt in
> Sektionen ("main, "contrib" und "non-free") und dann sortiert nach dem
Mmmh, im Wiki steht dazu nichts, aber ich habe dunkel in Erinnerung,
dass wir »Abschnitte« schreiben ...
> ersten Buchstaben des Quellpaketes. Diese Verzeichnisse enthalten
> zahlreiche Dateien: die Bin*r-Pakete f*r jede Architektur und die
> Quellpakete von denen die Bin*r-Pakete erstellt wurden.
Ich würde »Binärpakete« ohne Bindestrich schreiben.
> Es ist m*glich, herauszufinden wo ein Paket platziert ist, in dem man
> apt-cache showsrc paketname ausf*hrt und dann die "Directory"-Zeile
> betrachtet. Z.B. liegt das apache Paket in pool/main/a/apache.
>
> Zus*tzlich werden die lib* Pakete extra behandelt, da es einfach sehr
> viele sind: z.B. sind libpaper Pakete in pool/main/libp/libpaper/
> gespeichert.
>
> Historisch betrachtet wurden Pakete fr*her in einem Unterverzeichnis von
> dists, abh*ngig davon zu welcher Distribution sie geh*rten, gelagert. Dies
abhängig von der Zugehörigkeit zu einer Distribution
> verursachte zahlreiche Probleme, z.B. gro*en Bandbreitenverbrauch wenn
> gr**ere *nderungen an einem Mirror vorgenommen wurden. Durch die
s/Mirror/Spiegel/
> Einf*hrung des Paket-Pools konnte dies umgangen werden.
s/konnte dies/konnten diese/
> The dists directories are still used for the index files used by programs
> like apt. You may also still see paths containing dists/potato or
> dists/woody in the Filename header field of some older packages. Was ist
> "incoming"?
Hier fehlt die Übersetzung?
> Nachdem ein Entwickler ein Paket hochgeladen hat bleibt es f*r eine kurze
> Zeit in dem "incoming" Verzeichnis bis es auf seine Echtheit *berpr*ft
> wurde und damit in das Archiv darf.
>
> Im Normalfall sollte niemand etwas von dort installieren. Allerdings gibt
> es seltene Notf*lle. Das "incoming" Verzeichnis ist unter verf*gbar. Es
> ist m*glich, Pakete von dort per Hand zu holen, die GPG Signatur und
> MD5-Checksumme in den .changes und .dsc Dateien zu *berpr*fen und sie dann
> zu installieren. Wie erstelle ich mein eigenes, apt-taugliches Paketdepot?
>
> Wenn man eigene Debian Pakete gebaut hat und diese mit den standard Debian
> Paketwerkzeugen installieren m*chtest, so ist es m*glich ein eigenes
s/möchtest/möchte/
> apt-taugliches Paketarchiv zu erstellen. Dies ist auch n*tzlich wenn man
> eigene Debian Pakete verteilen m*chte, welche nicht vom Debian Projekt
> verteilt werden. Informationen und Anleitungen wie dies zu bewerkstelligen
> ist findet man unter .
Doppelte Fehler habe ich oft nicht markiert, also bitte jede Korrektur
global anwenden.
Viele Grüße
Helge
--
Dr. Helge Kreutzmann, Dipl.-Phys. Helge.Kreutzmann@itp.uni-hannover.de
gpg signed mail preferred
64bit GNU powered http://www.itp.uni-hannover.de/~kreutzm
Help keep free software "libre": http://www.ffii.de/
Attachment:
pgpyXVVA8dl2Y.pgp
Description: PGP signature