NAME¶

multistrap - Bootstraps für mehrere Depots

ÜBERSICHT¶

 multistrap [-a ARCH] [-d VERZ] -f KONFIGURATIONSDATEI
 multistrap [--simulate] -f KONFIGURATIONSDATEI
 multistrap -?|-h|--help|--version

OPTIONEN¶

-?|-h|--help|--version - den Hilfetext ausgeben und erfolgreich beenden --dry-run - alle Konfigurationseinstellungen zusammenstellen und eine Kurzfassung ausgeben --simulate - entspricht --dry-run (Die folgenden Optionen können auch in der Konfigurationsdatei gesetzt werden.) a|--arch - Architektur der Pakete, die in den Multistrap hineinkommen -d|--dir - Verzeichnis in das der Bootstrap installiert wird -f|--file - Konfigurationsdatei für Multistrap [erforderlich] -s|--shortcut - verkürzte Version von -f für Dateien an bekannten Orten --tidy-up - die Apt-Zwischenspeicherdaten, heruntergeladene Paketdateien und den Apt-Paketzwischenspeicher entfernen. Entspricht cleanup=true. --no-auth - die Benutzung von nicht authentifizierten Depots erlauben. Entspricht noauth=true --source-dir VERZ - verschiebt die Inhalte von var/cache/apt/archives/ aus der Chroot in das angegebene externe Verzeichnis und fügt dann die Debian-Quellpakete für jedes benutzte Programm hinzu. Entspricht retainsources=VERZ. Falls das angegebene Verzeichnis nicht existiert, passiert nichts. Benötigt --tidy-up, um die vollständige Liste der Quellpakete einschließlich Abhängigkeiten zu berechnen.

BESCHREIBUNG¶

Multistrap stellt mehrere Debootstrap ähnliche Methoden bereit, die auf APT basieren, erweitert um die Unterstützung für mehrere Depots; dabei wird eine Konfigurationsdatei verwendet, um relevante Suites, Architekturen, zusätzliche Pakete und den Spiegel anzugeben, die für jeden Bootstrap benutzt werden. Das Ziel ist es, ein komplettes Bootstrap-/Wurzeldateisystem mit allen installierten und konfigurierten Paketen zu erstellen, statt nur eines Basissystems. In den meisten Fällen möchten Anwender die Konfigurationsdatei für jede unterschiedliche Multistrap-Benutzung erstellen. Beispielkonfiguration:

 [General]
 arch=armel
 directory=/opt/multistrap/
 # entspricht der Option --tidy-up, falls auf »true« gesetzt
 cleanup=true
 # entspricht der Option --no-auth, falls auf »true« gesetzt
 # pro Bootstrap aufgeführte Keyring-Pakete werden trotzdem installiert
 noauth=false
 # alle heruntergeladenen Pakete extrahieren (Vorgabe ist »true«).
 unpack=true
 # ob die »/suite« hinzugefügt wird, um explizit festzulegen, wo APT
 # nach Paketen suchen muss. (Vorgabe ist »false«)
 explicitsuite=false
 # aktiviert Multiarch für die angegebenen Architekturen
 # Vorgabe ist leer
 multiarch=
 # »aptsources« ist eine Liste von Abschnitten, die die 
 # /etc/apt/sources.list.d/multistrap.sources.list des Ziels benutzen.
 # Die Reihenfolge spielt keine Rolle.
 aptsources=Debian
 # Die Bootstrap-Option legt fest, welches Depot zur Berechnung der
 # Prioritätsliste benutzt wird: Benötigte Pakete und welche Pakete in das
 # Wurzeldateisystem wandern.
 # Die Reihenfolge der Abschnitte spielt keine Rolle.
 bootstrap=Debian
 
 [Debian]
 packages=
 source=http://ftp.uk.debian.org/debian
 keyring=debian-archive-keyring
 suite=lenny

Dies wird zu einem völlig normalen Bootstrap von Debian-Lenny vom angegebenen Spiegel für Armel in »/opt/multistrap/« führen. (Diese Konfiguration wurde im Paket als /usr/share/multistrap/lenny.conf beibehalten.) Geben Sie ein Paket zur Erweiterung von Multistrap an, um das Paket und alle Abhängigkeiten des Pakets einzufügen. Geben Sie weitere Depots für den Bootstrap an, indem Sie neue Abschnitte hinzufügen. Abschnittsnamen müssen für die Pakete in der »Bootstrap«-Option unter [General] aufgelistet sein, um in den Bootstrap eingefügt zu werden. Geben Sie durch Auflisten der Abschnittsnamen in der «aptsources«-Option unter [General] an, welche Depots im fertigen System beim Start verfügbar sein sollen, z.B. um einige interne Quellen auszuschließen oder wenn ein lokaler Spiegel beim Erstellen des Wurzeldateisystems benutzt wird. Abschnittsnamen sind von Groß- und Kleinschreibung unabhängig Alle Abhängigkeiten werden nur durch Apt unter Benutzung aller Bootstrap-Depots aufgelöst, um nur die neusten und tauglichsten Abhängigkeiten zu benutzen. Beachten Sie, dass Multistrap Installationsempfehlungen ignoriert, so dass ein Paket, das von Multistrap benötigt wird und das nur eine empfohlene Abhängigkeit hat, explizit in der Paketzeile angegeben werden muss. Lesen Sie "Explizite Angabe der Suite", um weitere Informationen über den Erhalt spezieller Pakete von speziellen Suites zu bekommen. »architecture« und »directory« können auf der Befehlszeile überschrieben werden. Einige andere allgemeine Optionen besitzen auch Befehlszeilenoptionen.

Kürzel¶

Auf eine ähnliche Weise wie "Debootstrap" unterstützt "Multistrap" auf Konfigurationsdateien an bekannten Orten über Kürzel Bezug zu nehmen. Wenn die Option "--shortcut" benutzt wird, wird Multistrap in /usr/share/multistrap und dann in /etc/multistrap.d/ nach Dateien suchen. Dabei wird eine ».conf«-Erweiterung an das angegebene Kürzel angehängt. Diese beiden Befehle sind gleichwertig:

 $ sudo multistrap -s sid
 $ sudo multistrap -f /usr/share/multistrap/sid.conf

Beachten Sie, dass "Multistrap" auch weiterhin scheitern wird, wenn die Konfigurationsdatei nicht das Verzeichnis oder die Architektur setzt.

Depots¶

"aptsources" listet die Abschnitte auf, die benutzt werden sollen, um die /etc/apt/sources.list.d/multistrap.list-Apt-Quellen im fertigen System zu erstellen. Nicht alle "aptsources" müssen im Abschnitt "Bootstrap" erscheinen, falls Sie interne oder lokale Quellen haben, die für das installierte Wurzel-Dateisystem nicht verfügbar sind. "aptsources" listet die Abschnitte auf, die benutzt werden sollen, um Multistrap selbst zu erstellen. Nur Pakete, die in "Bootstrap" aufgelistet sind, werden durch den Multistrap heruntergeladen und entpackt. Stellen Sie sicher, dass "Bootstrap" alle Abschnitte auflistet, die Sie für Apt benötigen, um in der Lage zu sein alle Pakete zu finden, die für den Multistrap entpackt werden. (Ältere Versionen von Multistrap unterstützen die gleiche Option unter dem "Debootstrap"-Namen – diese Schreibweise wird immer noch unterstützt, aber neuere Versionen sollten stattdessen "Bootstrap" benutzen.

Allgemeine Einstellungen:¶

»arch« kann auf der Befehlszeile mit der Option "--arch" überschrieben werden. »directory« gibt das Verzeichnis auf der obersten Ebene an, auf der der Bootstrap erstellt wird – es wird nicht in ein .tgz gepackt, sobald es vollständig ist. »bootstrap« listet die Abschnitte auf, die zur Angabe der Pakete benutzt werden, die in den Bootstrap heruntergeladen (und optional entpackt) werden. »aptsources« listet die Abschnitte auf, die zur Angabe der Apt-Quellen im fertigen System benutzt werden, z.B. falls Sie ein lokales Depot benutzen müssen, um das Wurzeldateisystem zu generieren, das dem Gerät zur Laufzeit nicht zur Verfügung stehen wird, führen Sie den Abschnitt in "bootstrap" auf, aber nicht in "aptsources". Wenn Sie ein Paket im Wurzel-Dateisystem haben möchten, muss es in der "Bootstrap"-Liste unter »General« aufgelistet sein. Die Reihenfolge der Abschnittsnamen in beiden Listen ist unwichtig. Wie auch Debootstrap wird Multistrap nach Fehlern so lange fortfahren, wie die Konfigurationsdatei korrekt ausgewertet werden kann. Multistrap implementiert außerdem die Unterstützung für »machine:variant«, die ursprünglich in Emdebian-Crush benutzt wurde, wenngleich in einer anderen Implementierung. Bei Benutzung der stufenförmigen Konfigurationsunterstützung können bestimmte »machine:variant«-Kombinationen durch einfache Änderungen auf der Befehlszeile unterstützt werden. Wenn "tarballname" auf »true« gesetzt wird, wird das fertige Dateisystem zusätzlich in einen Tarball gepackt. Beachten Sie, dass Multistrap unbekannte Optionen in der Konfigurationsdatei ignoriert – dies erlaubt sowohl rückwärtskompatibles Verhalten als auch Überladen der Multistrap-Konfigurationsdateien, um andere Werkzeuge zu unterstützen (wie »pbuilder«). Benutzen Sie die Option "--simulate", um die kombinierten Konfigurationseinstellungen zu sehen. Falls jedoch die Konfigurationsdatei selbst nicht ausgewertet werden kann, wird Multistrap abgebrochen. Prüfen Sie, ob die Konfigurationsdatei in jeder Zeile außer in Kommentaren einen Schlüssel und einen Wert hat. Alle Werte müssen in der gleichen Zeile wie ihr Schlüssel stehen.

Abschnittseinstellungen¶

 [Debian]
 packages=
 source=http://ftp.uk.debian.org/debian
 keyring=debian-archive-keyring
 suite=lenny

Der Abschnittsname (in »[]«-Klammern) muss in dieser Konfigurationsdatei und in allen Konfigurationsdateien, die in dieser enthalten sind, einmalig sein. Abschnittsnamen sind nicht von Groß- und Kleinschreibung abhängig (alle Vergleiche finden nach der Umwandlung in Kleinschreibung statt). »packages« ist die Liste der Pakete, die hinzugefügt werden, wenn dieser Abschnitt in "Bootstrap" aufgelistet ist – alle Paketnamen müssen in einer einzigen Zeile aufgeführt sein, sonst scheitert die Auswertung der Datei. Alternativ können Sie Ihre Paketliste in Form mehrerer Gruppen mit Paketen, die auf funktionaler Basis oder Abhängigkeitsbasis unterteilt werden, definieren z.B. base, Xorg, networking etc. und jede Gruppe unter »bootstrap« aufführen.

 bootstrap=base networking
 [base]
 packages=udev mtd-utils
 source=http://www.emdebian.org/grip
 keyring=emdebian-archive-keyring
 suite=lenny
 [networking]
 packages=netbase ifupdown iproute net-tools samba
 source=http://www.emdebian.org/grip
 keyring=emdebian-archive-keyring
 suite=lenny

Als Sonderfall unterstützt "Multistrap" auch Paketschlüssel pro Abschnitt, einen je Zeile. Andere Schlüssel können nicht auf diese Art wiederholt werden.

 [Emdebian]
 packages=udev mtd-utils netbase ifupdown iproute
 packages=busybox net-tools samba
 source=http://www.emdebian.org/grip
 keyring=emdebian-archive-keyring
 suite=lenny

»source« ist die APT-Quelle, die für diesen Abschnitt benutzt wird. Um eine lokale Quelle auf der gleichen Maschine zu benutzen, stellen Sie sicher, dass Sie "copy://" und nicht "file://" benutzen, so dass Apt mitgeteilt wird, dass die Pakete in das Wurzel-Dateisystem kopiert werden müssen, anstatt davon auszugehen, dass sie später herunterladen werden müssen – weil dieses »später« tatsächlich nie stattfinden wird. »keyring« listet die Pakete auf, die den Schlüssel enthalten, die von den Quellen in diesem Abschnitt benutzt werden. Falls »keyring« nicht angegeben ist, muss die Option "noauth" auf »true« gesetzt sein. Siehe »Secure-Apt«. »suite« ist die Suite, die von dieser Quelle benutzt wird. Beachten Sie, dass dies die Suite sein sollte, nicht der Codename. Suites ändern sich von Zeit zu Zeit: (Oldstable, Stable, Testing, Sid). Der Codename (Etch, Lenny, Squeeze, Sid) ändert sich nicht.

Secure-Apt¶

Um authentifizierte Apt-Depots zu benutzen, muss Multistrap entweder in der Lage sein, ein geeignetes »keyring«-Paket aus den existierenden Apt-Quellen außerhalb der Multistrap-Umgebung in das Zielsystem zu installieren. Leider können keyring«-Pakete nicht aus den in der Multistrap-Konfiguration angegebenen Depots heruntergeladen werden – dies rührt daher, dass "Apt" den »keyring« zur Aktualisierung benötigt bevor Depots benutzt werden können, die vorher unbekannt waren. Falls relevante Pakete existieren, geben Sie diese in der »keyring«-Option für jedes Depot an. Multistrap wird dann prüfen, ob Apt dieses Paket bereits installiert hat, so dass das Depot authentifiziert wird, bevor Pakete daraus heruntergeladen werden. Beachten Sie, dass alle Depots, die mit Multistrap benutzt werden, authentifiziert sein müssen, sonst schlägt Apt fehl. Gleichermaßen kann Apt-Secure nur für alle Depots ausgeschaltet werden (durch Benutzen der Befehlszeilenoption --no-auth oder Setzen der Option »noauth« unter [General] in der Konfigurationsdatei), auch wenn nur ein Depot über keinen geeigneten »keyring« verfügt. Die »keyring«-Pakete werden außerdem innerhalb der Multistrap-Umgebung installiert, um für die installierten Apt-Quellen für Multistrap passend zu sein.

Status¶

Multistrap ist zustandslos – falls das Verzeichnis existiert, wird es einfach normal weitermachen und Apt wird nicht versuchen fortzufahren, wo es aufgehört hat.

Konfiguration des Wurzel-Dateisystems¶

Multistrap entpackt die heruntergeladenen Pakete, aber andere Stufen der Systemkonfiguration werden nicht durchgeführt. Enthaltene Beispiele:

 /etc/inittab
 /etc/fstab
 /etc/hosts
 /etc/securetty
 /etc/modules
 /etc/hostname
 /etc/network/interfaces
 /etc/init.d
 /etc/dhcp3

Jegliche gerätespezifischen Geräteknoten müssen außerdem unter Benutzung von MAKEDEV oder "device-table.pl" erstellt werden – einem Hilfsskript, das mit MAKEDEV-Problemen umgehen kann. device-table.pl benötigt eine Gerätetabellendatei nach dem Vorbild derjenigen im Quellpaket »mtd-utils«. Siehe /usr/share/doc/multistrap/examples/device_table.txt Sobald Multistrap die das grundsätzliche Datei- und das Verzeichnislayout erfolgreich erstellt hat, werden andere gerätespezifische Skripte benötigt, bevor das Dateisystem entpackt und auf dem Zielgerät installiert werden kann. Sobald sie installiert sind, müssen die Pakete selbst unter Benutzung der Paketbetreuerskripte und "dpkg --configure -a" konfiguriert werden, außer wenn dies ein nativer Multistrap ist. Damit "Dpkg" funktioniert, müssen /proc und /sysfs eingehängt (oder einhängbar) sein, /dev/pts wird ebenfalls empfohlen. Siehe auch: http://wiki.debian.org/Multistrap

Umgebung¶

Um die entpackten Pakete (ob im nativen oder Kreuzmodus) zu konfigurieren, werden bestimmte Umgebungsvariablen benötigt: Debconf muss mitgeteilt werden, dass eine Interaktion mit dem Benutzer nicht erwünscht ist:

 DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true

Perl muss mitgeteilt werden, dass es ohne Beschwerde akzeptieren soll, dass innerhalb der Chroot keine Locales verfügbar sind.

 LC_ALL=C LANGUAGE=C LANG=C

Dann können die Pakete von Dpkg konfiguriert werden: Chroot-Methode (PFAD = Oberstes Verzeichnis der Chroot):

 DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true \
 LC_ALL=C LANGUAGE=C LANG=C chroot /PATH/ dpkg --configure -a

in einer Anmelde-Shell:

 # export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true
 # export LC_ALL=C LANGUAGE=C LANG=C 
 # dpkg --configure -a

(Wie oben bereits erwähnt erfordert Dpkg, dass /proc und /sysfs zuerst eingehängt werden.)

Nativer Modus – Multistrap¶

Multistrap war nicht für native Unterstützung gedacht, es wurde entwickelt für Unterstützung über Architekturgrenzen hinweg. Um mehrere Depots benutzen zu können, entpackt Multistrap lediglich die von Apt ausgewählten Pakete. Im nativen Modus werden wahrscheinlich verschiedene Operationen benötigt, die Multistrap vorausgehen müssen; dies würde Debootstrap alles für Sie erledigen:

 1. Kopieren von /etc/hosts in den Chroot
 2. Bereinigen der Umgebung, so dass LANGUAGE, LC_ALL und LANG geleert
    werden, um störende Perl-Warnungen unterdrücken, die andere Fehler
    verschleiern könnten.

(Eine Alternative zum Leeren der Lokalisierungsvariablen ist es, Locales zu Ihrer Multistrap-Konfigurationsdatei in der »packages«-Option hinzuzufügen. Ein natives Multistrap kann direkt mit Chroot benutzt werden, so dass "Multistrap" am Ende des Multistrap-Prozesses "dpkg --configure -a" ausführt, falls die Option ignorenativearch nicht im Abschnitt General der Konfigurationsdatei auf »true« gesetzt ist.

Daemons in Chroots¶

Abhängig davon, welches System Sie benutzen, um Pakete für "Multistrap" bereitzustellen, sollten native Chroots Daemons nicht erlauben innerhalb des Chroots zu starten. Benutzen Sie als Ihr "Einrichtungsskript" /usr/share/multistrap/chroot.sh oder fügen Sie dieses Skript in Ihr eigenes Einrichtungsskript ein.

 setupscript=/usr/share/multistrap/chroot.sh

chroot.sh meistert Systeme, die sysvinit and upstart benutzen. Siehe auch

 http://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt

Stufenförmige Konfiguration¶

Damit Multistrap mehrere Varianten der (üblichen) Basiskonfiguration unterstützt, erlauben es die Konfigurationsdateien von "Multistrap", andere (allgemeinere) Konfigurationsdateien einzuschließen, z.B. wird die ausführlichere/speziellere Konfigurationsdatei auf der Befehlszeile angegeben und diese Datei enthält eine andere Datei, die sie sich mit anderen Konfigurationen teilt. Basisdatei:

 /usr/share/multistrap/crosschroot.conf

Variationen:

 /usr/share/multistrap/armel.conf

Wenn Sie nur die Datei »armel.conf« angeben, wird der Rest der Einstellungen von »crosschroot.conf« abgefragt, so dass übliche Änderungen nur in einer einzelnen Datei vorgenommen werden müssen. Es wird dringend empfohlen, dass jegliche Änderungen an den beteiligten Konfigurationsdateien in jeder Stufe mit der Option "--simulate" für Multistrap getestet werden, was eine Zusammenfassung der Optionen ausgibt, die gesetzt werden, wenn die Kaskade komplett ist. Beachten Sie, dass Multistrap Sie nicht warnt, falls eine Konfigurationsdatei eine unbekannte Option enthält (für zukünftige Konfigurationen mit Backport-Konfigurationen), so dass ein einfacher Tippfehler dazu führen kann, dass Optionen nicht gesetzt werden.

»Machine:variant«-Unterstützung¶

Die alten »packages.conf«-Variablen von Emsandbox können alle in Multistrap-Konfigurationsvariablen umgewandelt werden. Die »Machine:variant«-Unterstützung in "Multistrap" konzentriert sich auf die Skripte config.sh und setup.sh Anmerkung: Die Unterstützung für »machine:variant« wird wahrscheinlich durch die nachfolgend beschriebene Hook-Funktionalität ersetzt Sobald "Multistrap" die heruntergeladenen Pakete entpackt hat, kann "setup.sh" unter der Angabe des Ortes und der Architektur aufgerufen werden, so dass andere Feineinstellungen ihren Platz einnehmen können. In diesem Schritt dürfen keine Operationen innerhalb des Wurzeldateisystems einer fremden Architektur versuchen, irgendwelche Programme innerhalb des Wurzeldateisystems auszuführen. Als letzter Schritt des Multistrap-Prozesses wird "config.sh" in das Wurzelverzeichnis des Wurzeldateisystems kopiert. Ein Vorteil bei der Benutzung der »Machine:variant«-Unterstützung ist es, dass das vollständige Wurzeldateisystem mit einem einzigen Aufruf von Multistrap verwaltet werden kann – dies ist nützlich, wenn Wurzeldateisysteme im Bereich des Anwenders (»Userspace«) erstellt werden. Um »Machine:variant«-Unterstützung zu aktivieren, geben Sie den Pfad zu den Skripten, die ausgeführt werden sollen, in der Variant-Konfigurationsdatei (Abschnitt »General«) an:

 [General]
 include=/path/to/general.conf
 setupscript=/path/to/setup.sh
 configscript=/path/to/config.sh

Paketauswahl einschränken¶

"Multistrap" schließt standardmäßig benötigte Pakete ein, die aktuelle Liste der Pakete auf Ihrer eigenen Maschine kann angesehen werden unter Benutzung von:

 grep-available  -FPriority 'required' -sPackage

(Die aktuelle Liste wird aus der heruntergeladenen Datei Packages berechnet und kann sich von der Ausgabe von "grep-available" unterscheiden.) Falls die Option OmitRequired auf »true« gesetzt ist, werden diese Pakete nicht hinzugefügt – obwohl diese Option nützlich ist, kann sie zu einem unbrauchbaren Wurzeldateisystem führen. Nur manuell in den Konfigurationsdateien angegebenen Pakete werden in den Berechnungen benutzt – Abhängigkeiten dieser Pakete werden hinzugefügt, aber keine anderen.

Pakete mit »Priority: important« hinzufügen¶

"Multistrap" kann "Debootstrap" imitieren, indem es automatisch alle Pakete aus allen Abschnitten hinzufügt, bei denen die heruntergeladene Datei Packages das Paket mit »Priority: important« auflistet. Standardmäßig werden solche Pakete nicht hinzugefügt, sofern sie nicht einzeln in einer "packages="-Option eingefügt werden, die in einem angegebenen Abschnitt in der "Bootstrap"-Option [General] angegeben ist. Um all diese Pakete hinzuzufügen, setzen Sie die Option »addimportant« im Abschnitt [General] auf »true«.

 addimportant=true

»Priority: important« kann nur für alle Abschnitte funktionieren, die in der Option "bootstrap" aufgelistet sind. Dies kann Verwirrung stiften, wenn Suites gemixt werden. Es ist nicht möglich »addimportant« und »omitrequired« in der gleichen Konfiguration einzuschalten. "Multistrap" wird mit Fehlercode 7 beendet, falls sowohl irgendwelche Konfigurationsergebnisse in »addimportant« als auch in »omitrequired« auf »true« gesetzt sind. (Dies beinhaltet die Auswirkungen vom Einschluß anderer Konfigurationsdateien.)

Empfohlenes Verhalten¶

Das Debian-Standardverhalten nach der Veröffentlichung von Lenny war es, empfohlene Pakete als zusätzliche Pakete zu berücksichtigen, die installiert werden, wenn irgendein Paket ausgewählt ist. Empfohlene Pakete sind solche, von denen der Paketbetreuer annimmt, dass dieses Paket auf den "meisten" Installationen vorhanden wäre und erlauben von Empfehlungen bedeutet erlaubte Empfehlungen empfohlener Pakete usw. Standardmäßig sind Empfehlungen in Multistrap AUSgeschaltet. Setzen Sie die Option »allowrecommends« ist im Abschnitt »General« »true«, um typisches Debian-Verhalten zu bekommen.

Standardveröffentlichung¶

Falls Ihr System eine Standardveröffentlichung für APT angibt, kann dies Probleme verursachen, wenn Sie versuchen, einen Bootstrap zu erstellen, der die Vorgabesuite nicht enthält. Dem setzt "Multistrap" einen Platzhalter für die Standardveröffentlichung innerhalb des Bootstraps entgegen. Siehe auch: APT-Preferences.

Explizite Angabe der Suite¶

Manchmal soll Apt mitgeteilt werden, dass ein bestimmtes Paket aus einer bestimmten Suite empfangen werden soll, während dabei eine aktuellere Version in einer anderen Suite derselben Quellenzusammenstellung ignoriert wird. "Multistrap" kann mit oder ohne expliziter Suite-Option arbeiten, standardmäßig wird Apt die aktuellste Version aus der Sammlung angegebener Bootstrap-Quellen benutzen. Die explizite Angabe der Suite hat keine Auswirkung auf das fertig installierte System – falls Ihre »aptsources« ein Depot enthalten, das wiederum eine neuere Version des/der angegebenen Paket(s) explizit enthält, wird das nächste "apt-get upgrade" auf dem Gerät zu einer neueren Version führen. Außerdem wird Apt, wenn Pakete von einer speziellen Suite angegeben sind, auch versuchen und sicherstellen, dass die Abhängigkeiten für dieses Paket von der gleichen Suite stammen und dies kann der Grund sein, dass die Abhängigkeiten für dieses Paket von der gleichen Suite stammen; dies kann jedoch auch der Grund sein, warum apt nicht die komplette Zusammenstellung von Abhängigkeiten auflösen kann. In einer solchen Situation könnte es erforderlich sein, wenn Sie explizit ein Paket auswählen, dass Sie auch bei den abhängigen Paketen (nicht notwendigerweise allen) eine explizite Auswahl treffen müssen. Wenn diese Unterstützung in Lenny benutzt wird, stellen Sie sicher, dass in jedem Abschnitt im Konfigurationselement "Suite" die Suite benutzt wird (Oldstable, Stable, Testing, Sid) und nicht die Codenamen (Etch, Lenny, Squeeze, Sid) in dem Konfigurationselement "Suite", da die Version von Apt in Lenny und früher den Codenamen nicht benutzen kann. Für einen Test unter Lenny probieren Sie:

 $ sudo apt-get install apt/stable

Vergleichen Sie mit

 $ sudo apt-get install apt/lenny

Wenn Sie »explicitsuite« benutzen, müssen Sie beim Gebrauch von »stable-proposed-updates« oder anderen temporären Orten achtsam sein – falls das Paket in eine andere Suite migriert und aus der temporären Suite entfernt wird (wie mit *-proposed-updates), wird Multistrap das Paket nicht mehr finden. Es kann sehr schwierig sein, die explizite Behandlung der Suite richtig hinzukriegen. Im Allgemeinen ist es das Beste, eine kleine Bootstrap-Chroot Ihrer ursprünglichen Architektur zu erstellen, dann ein Chroot dort hinein vorzunehmen, die nötigen APT-Quellen hinzuzufügen und herauszufinden, welche Befehle nötig sind, um den korrekten Mix von Programmen zu bekommen. Vermeiden Sie die explizite Angabe von Versionen, um Probleme aus der Welt zu schaffen, die nur mit Suites funktionieren. Hier könnten APT-Preferences und Pinning nützlich sein, siehe APT-Preferences.

APT-Preferences¶

Falls eine geeignete Datei in der Option aptpreferences des Abschnitts General in der Konfigurationsdatei aufgeführt ist, wird diese Datei vor der ersten Verwendung in das APT-Preferences-Verzeichnis des Bootstraps kopiert. Wenn eine APT-Preferences-Datei bereitgestellt ist, wird das "Vorgabeveröffentlichungs"verhalten von "multistrap" deaktiviert. Wie auch bei anderen externen Skripten und Dateien liegt der Inhalt der APT-References-Datei jenseits des Geltungsbereichs dieser Handbuchseite. "Multistrap" versucht nicht, die bereitgestellte Datei zu überprüfen, außer, das esnsicherstellt, dass sie gelesen werden kann.

»deb-src«-Auflistungen werden ausgelassen¶

Einige Multistrap-Umgebungen benötigen keinen Zugriff auf die Debian-Quellen installierter Pakete, normalerweise ist dies nötig, wenn die Erstellung (oder Kreuzerstellung »cross build«) eines Chroot unter Benutzung von Multistrap vorbereitet wird. Um diese zusätzliche Quelle auszuschalten (und sowohl Zeit zum Herunterladen als auch »Apt-Cache«-Größe zu sparen), benutzen Sie das Feld »omitdebsrc« in jedem Abschnitt.

 [Baked]
 packages=
 source=http://www.emdebian.org/baked
 keyring=emdebian-archive-keyring
 suite=testing
 omitdebsrc=true

»omitdebsrc« ist nötig, wenn Pakete von Debian-Portierungen benutzt werden, bei denen Pakete keine Quellen außer »unreleased« haben.

fakeroot¶

Bootstraps für fremde Architekturen können unter "Fakeroot" arbeiten ("Multistrap" wurde entworfen, um soviel wie möglich in einem einzigen Aufruf zu erledigen, um dies einfacher zu machen), aber die bei einem nativen Architektur-Bootstrap verwendete Konfigurationsstufe erfordert "Chroot", und "Chroot" seinerseits funktioniert nicht unter "Fakeroot". Daher wird die Konfiguration im nativen Modus mit einer Warnmeldung übersprungen, falls "Multistrap" feststellt, dass "Fakeroot" gerade benutzt wird. Das gleiche Problem betrifft "apt-get install" und daher wird die Installation des Pakets »keyring« auf dem Host-System ebenfalls übersprungen, falls Fakeroot erkannt wird.

Handhabung problematischer Pakete¶

Manchmal schlägt sogar das korrekte Entpacken eines bestimmten Paketes fehl, falls ein anderes Paket nicht bereits entpackt wurde. Dies kann vorkommen, falls Dpkg-Umlenkungen nicht korrekt eingerichtet sind oder wenn das Paket vorher von einer ausführbaren Datei in einem anderen Paket abhängt. Multistrap bietet zwei Möglichkeiten diese Probleme zu handhaben. Ein Paket kann als "reinstall" oder "additional" aufgeführt werden. Jeder Abschnitt in der Konfigurationsdatei von "Multistrap" kann eine einzelne "reinstall"- oder "additional"-Auflistung haben oder beide. »reinstall« bedeutet, dass das Paket wie üblich heruntergeladen und entpackt wird – zusammen mit allen anderen Paketen, aber es wird dann am Ende durch Ausführen des Betreuerskripts "preinst" mit dem Argument "upgrade" neu installiert. "Dpkg" wird dann mit dem Rest der Konfiguration des Pakets fortfahren. »Additional« fügt dem Multistrap-Prozess eine zweite Runde von "apt-get install" hinzu – nach dem Entpacken am Anfang. Das zusätzliche Paket wird dann heruntergeladen und entpackt. Falls es im ursprünglichen Zustand ausgeführt wird, wird das zusätzliche Paket heruntergeladen, entpackt und konfiguriert, nachdem alle anderen Pakete heruntergeladen, entpackt und konfiguriert wurden. Weder "reinstall" noch "additional" sollten als mehr als nur Notlösungen betrachtet werden und es sollten in Debian »wishlist«-Fehler an Pakete gesandt werden, die diesen Mechanismus nutzen (oder die Pakete, die das spezielle Paket am normalen Funktionieren hindern würden).

Debconf-Voreinstellungen¶

Das Hinzufügen einer Debconf-Voreinstellung kann bei der Konfiguration von Paketen für eine bestimmte Einstellung an Stelle der Paketvorgaben helfen, wenn die Konfiguration nicht interaktiv abläuft. Informationen wie Voreinstellungsdateien erstellt werden, finden Sie unter http://www.debian-administration.org/articles/394. Sie können mehrere Voreinstellungsdateien über das Feld »debconfseed« im Abschnitt [General], getrennt durch Leerzeichen angeben:

 debconfseed=seed1 seed2

Dateien, die nicht existieren oder nicht geöffnet werden können, werden stillschweigend ignoriert. Prüfen Sie die Ergebnisse der Auswertung, indem Sie die Option "--simulate" von "Multistrap" verwenden.

Hooks¶

Falls ein Hook-Verzeichnis im Abschnitt [General] der "Multistrap"-Konfigurationsdatei angegeben wurde, werden die Hook-Skripte, die ausführbar sind, außerhalb des Multistrap-Verzeichnisses auf den folgenden Stufen ausgeführt:

Download-Hooks

wird vor dem Entpacken durchgeführt, sofort nachdem die Pakete heruntergeladen wurden. Download-Hooks sind ausführbare Skripte im angegebenen Hook-Verzeichnis, deren Dateiname mit download beginnt.

native hooks

Native Hook-Skripte werden nur im nativen Modus ausgeführt, unmittelbar bevor die Konfiguration der heruntergeladenen Pakete beginnt und erneut nach der Fertigstellung der Paket-Konfiguration. Native Hooks werden den absoluten Pfad, den derzeitigen Prozessstatus, Start oder Ende abfragen.

 

Native Skripte sind ausführbare Skripte im angegebenen Hook-Verzeichnis, deren Dateiname mit native beginnt.

Completion-Hooks

werden unmittelbar vor der Erstellung des Tarballs ausgeführt oder wenn "Multistrap" beendet wird, falls die Erstellung keines Tarballs konfiguriert wurde.

 

Completion-Skripte sind ausführbare Skripte im angegebenen Hook-Verzeichnis, deren Dateiname mit completion beginnt.

Hooks wird der absolute Pfad zum Verzeichnis übergeben, das das Wurzelverzeichnis des Chroot oder Multistrap-Systems sein wird. Hooks, die nicht mittels Realpath aufgelöst werden können oder die nicht ausführbar sind, werden ignoriert. Alle Hooks eines Typs werden vor dem Ausführen alphabetisch sortiert. Beachten Sie, dass "Multistrap" im Fehlerfall die Auswirkungen von Hooks nicht ungeschehen machen kann. "Multistrap" wird jedoch die angesammelten Fehler als Warnungen ausgeben. Falls ein Hook mit einem Fehlercode ungleich Null beendet wird, wird der Exit-Wert in eine positive Zahl umgewandelt, zur Anzahl der gesamten Warnungen hinzuaddiert und am Ende der Operation ausgegeben.

Ausgabe¶

"Multistrap" kann viele Ausgaben erzeugen – informative Nachrichten erscheinen auf der Standardausgabe, Fehler und Warnungen auf der Standardfehlerausgabe. Aufrufe von "Apt" und "Dpkg" folgen dem gleichen Muster, daher ist es einfach, falls gewünscht, die kombinierte Ausgabe von "Multistrap" auf reine Fehler zu kürzen. "Multistrap" sammelt Fehlerstati von nicht fatalen Prozessen innerhalb der Operation und gibt diese Warnungen sowohl auf der Standardfehlerausgabe als auch am Ende als kumulierte Fehleranzahl aus. Dies schließt Hooks ein, die Exit-Werte ungleich Null ausgeben.

Fehler¶

Da "Multistrap" immer komplexer wird, werden sich Fehler in das Paket einschleichen. Bitte berichten Sie alle Fehler mit der Werkzeug "Reportbug" an die Debian-Fehlerdatenbank. Hängen Sie bitte alle Konfigurationsdateien an. Falls Ihre Konfiguration Zugriff auf lokale oder private Apt-Depots erfordert, überprüfen Sie Ihre Konfiguration mit der letzten Version von "Multistrap" in Debian. Benutzen Sie die Option "--simulate" und fügen Sie deren Bericht in Ihren Fehlerbericht ein. Die Ausgabe der Option "--simulate" wird regelmäßig expandiert, um Anwendern bei der Fehlersuche in Konfigurationsdateien zu helfen. Bitte prüfen (und aktualisieren) Sie das Multistrap-Wiki unter http://wiki.debian.org/Multistrap und den Inhalt der Web-Seite unter http://www.emdebian.org/multistrap/ bevor Sie Fehlerberichte einreichen. Außerdem können mehrere Leute auf der Mailingliste debian-embedded@lists.debian.org und dem IRC-Kanal #emdebian auf irc.oftc.net helfen, falls Ihre Konfigurationsdatei nicht korrekt ausgewertet wird. Würden Sie die Ausgabe von "--simulate" auf eine Pastebin-Website ablegen und in Ihrer Nachricht die URL angeben.

Multiarch-Unterstützung¶

Multiarch-Unterstützung ist experimentell – bitte melden Sie Probleme und Dateifehler mit vollständigen Einzelheiten Ihrer Einrichtung, der vollständigen Konfigurationsdatei und gemeldeten Fehlern. "Multistrap" setzt die existierende Multiarch-Unterstützung des externen Systems außer Kraft, so dass ein System, das Multiarch kennt, immer noch eine Nicht-Multiarch-Chroot aus Depots erstellen kann, die nicht alle durch das externe Dpkg unterstützten Architekturen unterstützen. Falls Multiarch innerhalb der Multiarch-Chroot aktiviert ist, fertigt "Multistrap" die Liste in /var/lib/dpkg/arch innerhalb der Chroot aus. Geben Sie die Option für mehrere Architekturen einmal an und benutzen Sie eine durch Kommas getrennte Liste für die Architekturen. Stellen Sie sicher, dass Sie diejenige einbeziehen, die die Host-Architektur der Chroot sein wird. Siehe auch: http://wiki.debian.org/Multiarch/

 [General]
 ...
 multiarch=i386 armel armhf

Jeder Abschnitt wird Pakete von der Basisarchitektur installieren, es sei denn, für spezielle Abschnitte ist die Option "Architecture" angegeben.

 [Foreign]
 packages=libgcc1 libc6
 architecture=armel
 source=http://ftp.uk.debian.org/debian
 keyring=debian-archive-keyring
 suite=sid

In der Ausgabe von "--simulate" werden die in der Option MultiArch angegebenen Architekturen unter der Auflistung »Fremde Architekturen« aufgeführt. Pakete für eine besondere Architektur werden als der Paketname,

 libgcc1:armel libc6:armel