Nom¶

multistrap - bootstrap avec plusieurs dépôts

Synopsis¶

multistrap [-a ARCH] [-d RÉPERTOIRE] -f FICHIER_CONFIG multistrap [--simulate] -f FICHIER_CONFIG multistrap -?|-h|--help|--version

Options¶

-?|-h|--help|--version - afficher le texte d'aide et quitter correctement. --dry-run - examiner tous les paramètres de configuration et afficher un bref sommaire. --simulate - identique à --dry-run (Les options suivantes peuvent également être définies dans le fichier de configuration.) -a|--arch - architecture des paquets à insérer dans le multistrap. -d|--dir - répertoire dans lequel le bootstrap sera installé. -f|--file - fichier de configuration pour multistrap [requis] -s|--shortcut - version raccourcie de -f pour les fichiers dans des endroits connus. --tidy-up - supprimer les données du cache d'apt, les fichiers Packages téléchargés et le cache des paquets apt. Identique à cleanup=true. --no-auth - autoriser l'utilisation de dépôts non authentifiés. Identique à noauth=true --source-dir RÉP - déplacer le contenu de var/cache/apt/archives/ de l'intérieur du chroot vers le répertoire extérieur spécifié, puis ajoute les sources des paquets Debian pour chaque binaire utilisé. Identique à retainsources=RÉP si le répertoire indiqué n'existe pas, rien ne sera fait. --tidy-up est requis pour calculer la liste complète des paquets source en incluant les dépendances.

Description¶

multistrap fournit une méthode semblable à debootstrap, basée sur apt et permettant la gestion de dépôts multiples, en utilisant un fichier de configuration pour indiquer les versions de distribution, l'architecture, les paquets supplémentaires et le miroir à utiliser pour chaque bootstrap. Le but est de créer un système de fichiers racine / bootstrap complet avec tous les paquets installés et configurés, plutôt que de créer uniquement le système de base. Dans la plupart des cas, les utilisateurs devront créer un fichier de configuration pour chaque utilisation différente de multistrap. Exemple de configuration : [General]
arch=armel
directory=/opt/multistrap/
# identique à l'option --tidy-up si définie à vrai
nettoyage=true
# identique à l'option --no-auth si définie à vrai
# les paquets « keyring » indiqués dans chaque bootstrap seront
# toujours installés.
noauth=false
# extraire toutes les archives téléchargées (vrai par défaut)
unpack=true
# ajouter la /suite à être explicite à propos de l'endroit où apt
# doit chercher les paquets. (faux par défaut)
explicitsuite=false
# activer MultiArch pour les architectures indiquées
# vide par défaut
# aptsources est une liste de sections à utiliser
# le fichier /etc/apt/sources.list.d/multistrap.sources.list
# de la cible. L'ordre n'est pas important
aptsources=Debian
# l'option bootstrap détermine quel dépôt
# est utilisé pour calculer la liste des priorités : paquets nécessaires
# et quels paquets vont dans le système de fichiers racine (rootfs).
# L'ordre des sections n'est pas important
bootstrap=Debian [Debian]
packages=
source=http://ftp.uk.debian.org/debian
keyring=debian-archive-keyring
suite=lenny Cela se traduira par un bootstrap tout à fait ordinaire de Debian Lenny à partir du miroir indiqué, pour armel dans « /opt/multistrap/ ». (Cette configuration est conservée dans le paquet en tant que /usr/share/multistrap/lenny.conf) Indiquez un paquet pour étendre le multistrap afin d'inclure ce paquet et toutes les dépendances de ce paquet. Indiquez plus de dépôts pour le bootstrap en ajoutant de nouvelles sections. Les noms de sections doivent figurer dans les options générales de boostrap pour les paquets à inclure dans le bootstrap. Veuillez indiquer quels dépôts seront disponibles pour le système final lors du boot, en indiquant les noms de section dans les options générales de aptsource, par exemple pour exclure des sources internes ou quand vous utilisez un mirroir local pour compiler le système de fichiers racine. La casse des lettres n'est pas importante dans les noms de section. Toutes les dépendances sont résolues uniquement par apt, en utilisant tous les dépôts bootstrap, pour utiliser uniquement les dépendances les plus récentes et les plus appropriées. Notez que multistrap désactive Installation des paquets suggérés. Si le multistrap a besoin d'un paquet qui est seulement recommandé, ce paquet devra être indiqué explicitement à la ligne des paquets. Voir "Spécifications explicites des versions de distributions" pour obtenir plus d'informations sur la façon d'obtenir des paquets spécifiques depuis des versions de distribution spécifiques. « arch » et « directory » peuvent être outrepassés en ligne de commande. D'autres options générales peuvent aussi être indiquées en ligne de commande.

Raccourcis¶

De la même manière que "debootstrap", "multistrap" supporte de faire référence à des fichiers de configuration à des endroits connus par des raccourcis. Quand l'option "--shortcut" est utilisée, "multistrap" cherchera des fichiers dans /usr/share/multistrap puis dans /etc/multistrap.d/, ajoutant un suffixe « .conf » au raccourci indiqué. Ces deux commandes sont équivalentes :

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

Veuillez noter que "multistrap" échouera à chaque fois si le fichier de configuration lui même n'indique pas le répertoire ou l'architecture.

Dépôts¶

"aptsources" liste les sections qui devraient être utilisées pour créer le /etc/apt/sources.list.d/multistrap.list apt sources du système final. Tous les "aptsources" ne doivent pas obligatoirement apparaître dans la section "bootstrap" s'il y a des sources internes ou locales inaccessible par le système de fichiers racine installé. "bootstrap" liste les sections qui seront utilisées pour créer le multistrap lui-même. Seul les paquets indiqués dans "bootstrap" seront téléchargés et dépaquetés par multistrap. Il faut s'assurer que "bootstrap" liste toutes les sections nécessaires afin que apt puisse trouver tous les paquets devant être dépaquetés pour le multistrap. (Les anciennes versions de multistrap utilisaient la même option sous le nom "debootstrap" - cette écriture est toujours possible mais les nouveaux fichiers de configuration devraient plutôt être "bootstrap".

Paramètres généraux :¶

« arch » peut être outrepassé en ligne de commande en utilisant l'option "--arch". « directory » indique le répertoire au sommet de l'arborescence dans lequel le debootstrap sera créé - il n'est pas empaqueté en un .tgz une fois terminé. « bootstrap » liste les sections qui seront utilisées pour indiquer les paquets qui seront téléchargés (et éventuellement dépaquetés) dans le bootstrap. « aptsources » liste les Sections qui seront utilisées pour indiquer les sources d'apt dans le système final. Par exemple, si vous avez besoin d'un miroir local pour générer le système de fichiers racine qui ne sera pas disponible au démarrage, indiquez cette section dans "bootstrap" et pas dans "aptsources". Si vous souhaitez qu'un paquet soit dans le système de fichiers racine, il doit être indiqué dans la liste de "bootstrap" sous Général. L'ordre des noms de section dans n'importe quelle liste n'est pas important. Comme pour debootstrap, multistrap continuera après des erreurs aussi longtemps que le fichier de configuration peut être correctement interprété. multistrap implémente également la gestion des variantes machines utilisée initialement dans Emdebian Crush, bien que l'implémentation est différente. Utiliser la gestion de configuration en cascade (« cascading configuration ») permet des combinaisons de variantes machine spécifiques gérées par de simple changements sur la ligne de commande. Définir "tarballname" à vraie empaquette également le système de fichiers final dans un tarball. Veuillez noter que multistrap ne tient pas compte des options non reconnues dans le fichier de configuration - cela permet de garder une rétrocompatibilité ainsi que de surcharger les fichiers de configuration de multistrap pour gérer d'autres outils (comme pbuilder). Utilisez l'option "--simulate" pour voir les différentes combinaisons de paramètres. Néanmoins, si le fichier de configuration ne peut être lu, multistrap abandonnera. Vérifiez que le fichier de configuration possède une clé et une valeur pour chaque ligne, en dehors des commentaires. Les valeurs doivent toutes se trouver sur la même ligne que la clé.

Paramètres de la section¶

[Debian]
packages=
source=http://ftp.uk.debian.org/debian
keyring=debian-archive-keyring
suite=lenny Le nom de section (entre [] crochets) doit être unique pour ce fichier de configuration et tous les fichiers de configuration que ce fichier comporte. Les noms de section ne sont pas sensibles à la casse (toutes les comparaisons sont faites après la conversion en minuscules). « packages » est la liste des paquets devant être ajoutés quand la Section est indiquée dans "bootstrap" — tous les noms de paquets doivent être indiqués sur une seule ligne ou le fichier ne pourra être lu. Une alternative consiste à définir votre liste de paquets en groupes multiples avec les paquets séparés selon une base de dépendances fonctionnelles, comme Xorg, networking, etc. et indiqué chaque groupe sous « bootstrap ».

 bootstrap=base networking

[base]
packages=udev mtd-utils
source=http://www.emdebian.org/grip
keyring=emdebian-archive-keyring
suite=lenny [réseau]
packages=netbase ifupdown iproute net-tools samba
source=http://www.emdebian.org/grip
keyring=emdebian-archive-keyring
suite=lenny Exceptionnellement, "multistrap" prend aussi en charge plusieurs clés pour les paquets, une ligne chacune. Les autres clés ne pouvant être définies de la même manière. [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 » est la source apt à utiliser pour cette Section. Pour utiliser une source locale sur la même machine, assurez-vous d'utiliser "copy://" et pas "file://", de manière à dire à apt de copier les paquets dans le système de fichiers racine plutôt que d'essayer de les télécharger plus tard - parce que ce « plus tard » n'arrivera certainement jamais. « keyring » liste les paquets qui contiennent la clé utilisée par la source indiquée dans la Section. Si aucune clé n'est indiquée, l'option "noauth" doit être mise à actif. Voir Securiser Apt. « suite » est la suite à utiliser depuis cette source. Veuillez noter qu'il s'agit de la suite et non du nom de code. Les versions de distribution changent au fil du temps : (ancienne stable, stable, testing, sid). Le nom de code (etch, lenny, squeeze, sid) ne change pas.

Apt sécurisé¶

Pour utiliser des dépôts apt signés, multistrap doit pouvoir installer un paquet trousseau adéquat à partir des sources apt existantes en dehors de l'environnement multistrap, dans le système de destination. Malheureusement, les paquets de trousseau ne peuvent pas être téléchargés depuis les dépôts indiqués dans la configuration multistrap — ceci parce que "apt" nécessite que le trousseau soit mis à jour avant de pouvoir utiliser des dépôts non connus précédemment. Si ces paquets existent, indiquez-les dans l'option « keyring » pour chaque dépôt. multistrap vérifiera alors que apt a déjà installé ce paquet : ainsi le dépôt pourra être authentifié avant de télécharger des paquets. Notez que tous les dépôts devant être utilisés avec multistrap doivent être authentifiés sinon apt échouera. De même, la sécurisation d'apt ne peut être désactivée que pour tous les dépôts (en utilisant l'option --no-auth en ligne de commande ou en définissant l'option générale noauth dans le fichier de configuration), même s'il n'existe qu'un seul dépôt sans trousseau de clés convenable. Les paquets de trousseau de clés seront également installés à l'intérieur de l'environnement du multistrap pour correspondre avec les sources apt installés du multistrap.

État¶

multistrap est sans-état - si le répertoire existe, il procédera tout simplement de manière ordinaire et apt essaiera de reprendre là où il s'était arrêté.

Configuration du système de fichiers racine¶

multistrap décompresse les paquets téléchargés, mais d'autres étapes de la configuration du système ne sont pas tentées. Par exemple :

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

Tous les noeuds de périphériques doivent également être créés avec MAKEDEV or "device-table.pl" - un script d'aide pouvant résoudre certains problèmes de MAKEDEV. device-table.pl nécessite un fichier contenant une table de périphériques suivant les lignes de celui contenu dans les sources du paquet mtd-utils. Voir /usr/share/doc/multistrap/examples/device_table.txt Une fois que multistrap a réussi à créer la structure de base pour les fichiers et les répertoires, d'autres scripts spécifiques aux périphériques sont nécessaires avant que le système de fichiers puisse être installé sur le périphérique cible. Une fois installés, les paquets doivent eux-mêmes être configurés en utilisant les scripts du responsable du paquet et "dpkg --configure -a", à moins qu'il ne s'agisse d'un multistrap natif. Pour que "dpkg" puisse fonctionner, /proc et /sysfs doivent être montés (ou être montables), /dev/pts est également recommandé. Voir aussi : http://wiki.debian.org/Multistrap

Environnement¶

Pour configurer les paquets dépaquetés (que ce soit en mode croisé ou natif), certaines variables d'environnement sont nécessaires : Il est nécessaire de signaler à Debconf que l'interaction utilisateur n'est pas souhaitée :

 DEBIAN_FRONTEND=noninteractif DEBCONF_NONINTERACTIVE_SEEN=true

Il est nécessaire de signaler à Perl qu'aucune locale n'est disponible l'intérieur du chroot et de ne pas se plaindre :

 LC_ALL=C LANGUAGE=C LANG=C

Puis, dpkg peut configurer les paquets : méthode chroot (PATH = le répertoire de base du chroot) :

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

dans un interpréteur de commandes de connexion :

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

(Comme ci-dessus, dpkg a besoin que /proc et /sysfs soient montés en premier.)

mode natif - multistrap¶

multistrap n'était pas prévu pour le mode natif, il fut développé pour la gestion de plusieurs architectures. Pour que de multiples dépôts puissent être utilisés, multistrap dépaquette uniquement les paquets sélectionnés par apt. En mode natif, diverses opérations post-multistrap que debootstrap ferait pour vous sont probablement nécessaires : 1. copiez /etc/hosts dans le chroot
2. nettoyez l'environnement pour détruire LANGUAGE, LC_ALL and LANG
pour passer sous silence les nuisances des avertissements cachant d'autres erreurs (Une alternative pour détruire les variables de localisation est d'ajouter locales à votre fichier de configuration multistrap dans l'option « paquets ». A native multistrap can be used directly with chroot, so "multistrap" runs "dpkg --configure -a" at the end of the multistrap process, unless the ignorenativearch option is set to true in the General section of the configuration file.

Démons dans les chroots¶

En fonction du système que vous utilisez pour fournir les paquets pour "multistrap", les chroots natifs n'autorisent généralement pas les démons à démarrer au sein du chroot. Utilisez le /usr/share/multistrap/chroot.sh comme votre "setupscript" ou incluez ce script dans votre propre script d'installation.

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

chroot.sh sait fonctionner avec les systèmes utilisant sysvinit et upstart. Voir également

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

Configuration en cascade¶

Pour assurer les multiples variantes d'une configuration de base, "multistrap" permet d'inclure des fichiers de configuration (plus généraux) dans des fichiers de configuration. C'est-à-dire que le fichier de configuration le plus spécifique ou détaillé doit être indiqué à la ligne de commande et ce fichier inclut un fichier qui est partagé avec d'autres configurations. Fichier de base :

 /usr/share/multistrap/crosschroot.conf

Variations :

 /usr/share/multistrap/armel.conf

En indiquant uniquement le fichier armel.conf, le reste des paramètres sera obtenu à partir du fichier crosschroot.conf afin que les modifications communes ne doivent être réalisées que dans un seul fichier. Il est fortement recommandé pour toutes modifications dans les fichiers de configuration impliqués dans n'importe quelle cascade de les tester avec l'option "--simulate" de multistrap qui produira en sortie un résumé des options définies une fois la cascade effectuée. Il faut noter que multistrap n'avertit pas si un fichier de configuration contient une option non reconnue (afin d'assurer la compatibilité future avec les configurations rétroportées). Ainsi une simple faute de frappe peut être à l'origine d'une option non définie.

Gestion des variantes de Machines¶

Toutes les anciennes variables de packages.conf de emsandbox peuvent être converties en variables de configuration "mulistrap". L'assistance des variantes machines dans "multistrap" se concentre sur les scripts, config.sh et setup.sh Remarque : la prise nen charge de machine:variant sera vraisemblablement remplacée par le déclencheur décrit ci-dessous Une fois que "multistrap" a dépaqueté les paquets téléchargés, "setup.sh" peut être appelé, en passant l'emplacement et l'architecture du système de fichiers racine, pour que d'autre réglages fins puissent être effectués. À cette étape, toutes opérations à l'intérieur d'un système de fichiers racine étranger (rootfs) ne doivent pas tenter d'exécuter de binaires dans le rootfs. À la dernière étape du processus multistrap, "config.sh" est copié vers le répertoire root du système de fichiers racine. Un des avantages d'utiliser le support des variantes machines est que la totalité du système de fichiers racine peut être géré par un seul appel à multistrap - ceci est utile lors de la création de systèmes de fichiers racines dans l'espace utilisateur. Pour activer les variantes machines, il faut indiquer le chemin vers les scripts devant être appelés dans le fichier de configuration variant (Section Générale) :

 [General]
 include=/chemin/vers/general.conf
 setupscript=/chemin/vers/setup.sh
 configscript=/chemin/vers/config.sh

Restriction de la sélection des paquets¶

"multistrap" inclut les paquets requis par défaut, la liste actuelle des paquets sur votre machine personnelle peut être visualisée en utilisant :

 grep-available  -FPriority 'required' -sPackage

(La véritable liste est calculée à partir des paquets téléchargés et peut différer de la sortie de "grep-available".) Si l'option OmitRequired est définie à vraie, ces paquets ne seront pas ajoutés - bien qu'utile, cette option peut facilement conduire à un rootfs inutilisable. Seuls les paquets indiqués manuellement dans les fichiers de configuration seront utilisés dans les calculs - les dépendances de ces paquets seront également ajoutées mais aucun autre.

Ajout des paquet de priorité « important »¶

"multistrap" peut imiter "debootstrap" en ajoutant automatiquement tous les paquets depuis toutes les sections où le fichier des paquets téléchargés indique les paquets de priorité « important ». Le comportement par défaut est de ne pas ajouter de tels paquets tant qu'ils ne sont pas individuellement inclus dans une option "packages=", dans une section indiquée dans les options générales de "bootstrap". Pour ajouter tous ces paquets, réglez l'option addimportant sur vrai dans la section générale.

 addimportant=true

La priorité « important  ne peut être appliquée qu'aux sections indiquées dans l'option de "bootstrap". Cela pourrait entraîner de la confusion lors de mélanges de suites. Il est possible d'activer addimportant et omitrequired dans la même configuration. "multistrap" sortira avec le code d'erreur 7 si il est trouvé dans n'importe quelle configuration les options addimportant et omitrequired réglées sur vrai. (Ceci inclut les effets dûs à l'inclusion d'autres fichiers de configuration.)

Comportements recommandés¶

Après la version Lenny, le comportement par défaut de Debian était de prendre en compte les paquets recommandés comme des paquets supplémentaires quant au moins un paquet était sélectionné. Les paquets recommandés sont ceux que le mainteneur considère comme devant être présents dans la "plupart" des installations de ce paquet et autoriser les paquets recommandés signifie autoriser les recommandés des paquets eux-mêmes recommandés et ainsi de suite. Le comportement par défaut de multistrap est de désactiver les paquets recommandés. Placez l'option allowrecommands (autoriser les paquets suggérés) à true (oui) dans la section générale pour utiliser ce comportement usuel de Debian.

Default release¶

If your system specifies a default-release for apt, this can cause problems when trying to create a bootstrap which does not include the default suite. To counter this, "multistrap" sets a wildcard for the Default Release within the bootstrap. See also: apt preferences.

Spécification claire de la version de la distribution¶

Quelque fois, il faut dire explicitement à apt d'aller prendre un paquet en particulier depuis une version spécifique, en ignorant une version plus récente d'une autre version de la distribution dans la même liste de sources. "multistrap" peut fonctionner avec et sans la spécification explicite de la version de la distribution, le paramètre par défaut est de laisser apt utiliser la version la plus récente du catalogue des sources bootstrap indiquées. La spécification d'une version de distribution n'a pas d'effet sur le système final installé - si vos sources apt incluent un dépôt disposant d'une nouvelle version du paquet explicitement indiqué, le prochain "apt-get upgrade" sur la machine installera la nouvelle version. Également, quand vous indiquez des paquets à prendre depuis une version spécifique de la distribution, apt essaiera de s'assurer que les dépendances pour ce paquet viennent également de cette même version, ce qui peut occasionner des problèmes à apt pour résoudre l'ensemble de ces dépendances. Dans ce cas, indiquez explicitement un paquet peut entrainer le fait d'indiquer quelques (pas nécessairement toutes) dépendances de ce paquet également. Lors de l'utilisation de cette assistance dans Lenny, assurez-vous que chaque section utilise la version de distribution (oldstable, stable, testing, sid) et non le nom de code (etch, lenny, squeeze, sid) dans la configuration de la "version" puisque la version de apt dans Lenny et les précédentes distributions ne peuvent utiliser le nom de code. Pour tester, sur Lenny essayez : $ sudo apt-get install apt/stable Comparer avec $ sudo apt-get install apt/lenny Lors de l'utilisation de suite explicite, assurez vous d'utiliser stable-proposed-updates ou d'autres emplacements temporaires - si le paquet migre dans une autre suite et est supprimé de la suite temporaire (comme avec *-proposed-updates), multistrap ne pourra pas trouver le paquet. Explicit suite handling can be very hard to get right. In general, it is best to create a small bootstrap chroot of your native arch, then chroot into it, add the relevant apt sources and work out exactly what commands are necessary to get the correct mix of packages. Avoid specifying explicit versions to sort out problems, work with suites only. Apt preferences / pinning may be useful here, see Apt preferences.

Apt preferences¶

If a suitable file is listed in the aptpreferences option of the General section of the configuration file, this file will be copied into the apt preferences directory of the bootstrap before apt is first used. When an apt preferences file is provided, the "Default-Release" behaviour of "multistrap" is disabled. As with other external scripts and files, the content of the apt preferences file is beyond the scope of this manpage. "multistrap" does not try to verify the supplied file other than ensuring that it can be read.

Omission de la lecture de deb-src¶

Certains environnements multistrap ne nécessitent pas l'accès aux sources des paquets Debian durant l'installation, cela est typiquement nécessaire lors de la préparation d'une compilation (ou compilation croisée) chroot utilisant multistrap. Pour désactiver la source additionnelle (et raccourcir le temps de téléchargement et la taille du cache de apt), utilisez le champ omitdebsrc dans chaque Section.

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

omitdebsrc est nécessaire en cas d'utilisation de paquets en provenance de debian-ports où les paquets n'ont pas de sources, à l'exception de « non-delivrée ».

fakeroot¶

Les architectures bootstrap différentes peuvent fonctionner sous "fakeroot" ("multistrap" est conçu pour en faire le maximum qu'il peut au sein d'un même appel pour faciliter cette tâche) mais le niveau de configuration qui est normalement appliqué avec une architecture bootstrap native requiert "chroot" et "chroot" en lui même ne fonctionnera pas sous "fakeroot". Donc, si "multistrap" détecte que "fakeroot" est en cours d'utilisation, le mode de configuration natif est sauté avec un message de rappel. Le même problème apparait sur "apt-get install" et donc l'installation du paquet trousseau sur le système hôte est également sauté si fakeroot est détecté.

Gestion des paquets problématiques¶

Quelquefois, un paquet en particulier échouera même à se dépaqueter proprement si les autres paquets n'ont pas encore été dépaquetés. Cela peut arriver si les contournements de dpkg ne sont pas correctement configurés ou si les Pre-Depends du paquet dépendent d'un exécutable se trouvant dans un autre paquet. Multistrap offre deux façons de gérer ces problèmes. Un paquet peut être indiqué comme "reinstall" ou comme "additional". Chaque section dans le fichier de configuration de "multistrap" peut être indiqué seulement en tant que "reinstall" ou "additional" ou bien les deux. Reinstall signifie que le paquet sera téléchargé et dépaqueté normalement - aux côtés de tous les autres paquets, mais sera alors réinstallé à la fin en lançant le script du mainteneur "preinst" avec l'argument "upgrade". "dpkg" continuera alors le reste de la configuration de ce paquet. Additional ajoute un second tour de "apt-get install" au processus multistrap - après le dépaquetage initial. Le paquet additionnel sera alors téléchargé et dépaqueté. Lancé nativement, le paquet additionnel est téléchargé, dépaqueté et configuré après que tout le reste des paquets aient été téléchargés, dépaquetés et configurés. Ni "reinstall" ou "additional" ne devraient pas être perçus plus que de simples astuces et les bogues devant figurer sur la liste des souhaits devraient être remplis dans Debian pour des paquets qui nécessiteraient de tels mécanismes (ou les paquets qui empêcheraient le paquet en particulier de se comporter normalement).

Préconfiguration Debconf¶

Ajouter une préconfiguration Debconf peut aider à configurer des paquets sur un comportement en particulier au lieu de celui par défaut, lors de configuration en mode non-interactif. Voir http://www.debian-administration.org/articles/394 pour des informations sur comment créer des fichiers de préconfiguration. Il est possible d'indiquer des fichiers de préconfiguration multiples en utilisant le champ debconfseed dans la section [General], séparés par des espaces :

 debconfseed=seed1 seed2

Les fichiers qui n'existent pas ou qui ne peuvent être ouverts, seront ignorés silencieusement. Vérifiez les résultats de leur lecture en passant l'option "--simulate" à "multistrap".

Détournements¶

Si un répertoire contenant des déclencheurs est indiqué dans la section Général du fichier de configuration de "multistrap", les scripts de déclencheurs qui sont exécutables seront exécutés depuis l'extérieur du répertoire multistrap aux étapes suivantes :

Déclencheurs téléchargés

L'exécution avant le dépaquetage est démarré immédiatement après que les paquets aient été téléchargés. Les déclencheurs téléchargés sont des scripts exécutables dans le répertoire de déclencheurs indiqué, avec un nom de fichier commençant par download.

Déclencheurs natifs.

Les scripts de déclencheurs natifs sont exécutés uniquement dans le mode natif, juste avant de démarrer la configuration des paquets téléchargés et encore une fois après la fin de la configuration du paquet. Les déclencheurs natifs seront appelés avec le chemin absolu et l'état de progression actuel, démarré ou arrêté.

 

Les scripts natifs sont exécutables dans le répertoire de déclencheurs indiqué avec un nom de fichier commençant par native.

Déclencheurs de complétion

Exécuté juste avant, l'archive (« tarball ») est créée ou "multistrap" quitte s'il n'est pas configuré pour la créer.

 

Les scripts de complétion sont des scripts exécutés dans le répertoire indiqué avec un nom commençant par "completion".

Les déclencheurs sont passés avec le chemin absolu dans le répertoire qui sera le niveau parent du chroot ou du système multistrap. Tous les déclencheurs d'une même sorte sont triés par ordre alphabétique avant d'être lancés. Veuillez noter que "multistrap" ne fait pas de retour arrière des effets des déclencheurs en cas d'erreur. Cependant, "multistrap" rapportera les erreurs accumulées sous forme d'avertissement. Si un déclencheur quitte sur autre chose que zéro, la valeur de sortie est convertie vers un nombre positif et ajoutée à la somme totale des avertissements, affichée à la fin de l'opération.

Sortie¶

"multistrap" peut produire beaucoup de sortie - les messages d'information apparaissent sur STDOUT, les erreurs et les avertissement sur STDERR. Les appels vers "apt" et "dpkg" respectent le même modèle, pour qu'il soit simple d'ajuster la sortie combinée de "multistrap" sur les erreurs seulement, si désiré. "multistrap" accumule les états d'erreur des processus non fatals au sein de l'opération et les rapporte comme des avertissements sur STDERR en même temps que quitter avec le décompte des erreurs accumulées. Cela comprend les déclencheurs qui signalent des valeurs de retour différentes de zéro.

Bogues¶

Comme "multistrap" devient plus compliqué, des bogues s'insinuent dans le paquet. Veuillez rapporter ces bogues sur le BTS Debian en utilisant l'outil "reportbug" en incluant s'il vous plait les fichiers de configuration. Si votre configuration nécessite d'accéder à des dépôts apt locaux ou privés, veuillez vérifier votre configuration avec les dernières versions de "multistrap" dans Debian en utilisant l'option "--simulate" et inclure ce rapport dans votre rapport de bogue. La sortie de l'option "--simulate" est régulièrement enrichie pour aider les utilisateurs à pister les problèmes dans les fichiers de configuration. Veuillez également vérifier (et mettre à jour) le wiki de Multistrap à http://wiki.debian.org/Multistrap et le contenu de la page Internet de Multistrap à http://www.emdebian.org/multistrap/ avant de remplir des bogues. Plusieurs personnes sur la liste de diffusion debian-embedded@lists.debian.org et sur le canal IRC #emdebian sur irc.oftc.net peuvent également aider si votre fichier de configuration ne peut être parcouru correctement. Vous devrez alors poster la sortie de "--simulate" sur un site Internet de copier et coller et indiquer l'adresse dans votre message.

Support de MultiArch¶

Multiarch support is experimental - please report issues and file bugs with full details of your setup, the full multistrap config file and the errors reported. "multistrap" overrides the existing multiarch support of the external system so that a MultiArch aware system can still create a non-MultiArch chroot from repositories which do not support all of the architectures supported by the external dpkg. If multiarch is enabled within the multistrap chroot, "multistrap" writes out the list into /var/lib/dpkg/arch inside the chroot. For multiple architectures, specify the option once and use a space separated list for the architecture list. Ensure you include what will be the host architecture of the chroot. Voir aussi : http://wiki.debian.org/Multiarch

 [General]
 ...
 multiarch=i386 armel armhf

Chaque section installera les paquets depuis l'architecture de base tant que l'option "Architecture" n'est pas indiquée dans des sections particulières.

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

In the "--simulate" output, the architecture(s) specified in the MultiArch option will be listed under the "Foreign architectures" listing. Packages for a specific architecture will be listed as the package name followed by a colon followed by the architecture.

 libgcc1:armel libc6:armel