Provided by: multistrap_2.2.0ubuntu1_all 
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 ajouter 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
cleanup=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 ou non la /suite pour rendre explicite 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 des dépôts supplémentaires 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 Install-Recommands. Si le multistrap a besoin
d'un paquet qui est seulement recommandé, ce paquet devra donc ê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.
Online examples and documentation
"multistrap" supports a range of permutations, see the wiki and the emdebian website for
more information and example configurations:
http://wiki.debian.org/Multistrap
http://www.emdebian.org/multistrap/
"multistrap" includes an example configuration file with a full list of all supported
config file options: /usr/share/doc/multistrap/examples/full.conf
Raccourcis
De la même manière que "debootstrap", "multistrap" gère la 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 les
/etc/apt/sources.list.d/multistrap.list sources apt 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 inaccessibles par le système de fichiers racine
installé.
"bootstrap" liste les sections qui seront utilisées pour créer le multistrap lui-même.
Seuls 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 n'est pas important quelle que soit la liste.
If "markauto" is set to true, "multistrap" will request apt to mark all packages specified
in the combined "packages" list as manually installed and all dependencies not explicitly
listed as automatically installed in the APT extended state database. "markauto" can be
used independently of "unpack".
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 soit différente. Utiliser la gestion de
configuration en cascade (« cascading configuration ») permet des combinaisons de
variantes machines spécifiques gérées par de simples 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,
chacune sur une ligne. Les autres clés ne peuvent ê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ées pour le
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 ou
"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 ».
Un multistrap natif peut être directement utilisé avec chroot, ainsi "multistrap" exécute
"dpkg --configure -a" à la fin du processus du multistrap à moins que l'option
ignorenativearch soit réglée sur true dans la section General du fichier de configuration.
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 : 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, aucune opération à
l'intérieur d'un système de fichiers racine étranger (rootfs) ne doit 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 la gestion des variantes machines est que la totalité du
système de fichiers racine peut être gérée 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
Ensure that both the setupscript and the configscript are executable or "multistrap" will
ignore the script.
Example configscript.sh
#!/bin/sh
set -e
export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true
export LC_ALL=C LANGUAGE=C LANG=C
/var/lib/dpkg/info/dash.preinst install
dpkg --configure -a
mount proc -t proc /proc
dpkg --configure -a
umount /proc
For more information, see the Wiki: http://wiki.debian.org/Multistrap
Mounting /dev and /proc for chroot configuration
/proc can be mounted inside the chroot, as above:
mount proc -t proc /proc
However, /dev should be mounted from outside the chroot, before running any
"configscript.sh" in the chroot:
cd /path/chroot/
sudo tar -xzf /path/multistrap.tgz
sudo mount /dev -o bind ./dev/
sudo chroot . ./configscript.sh || true
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 à vrai, 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 n'est pas possible d'activer addimportant et omitrequired dans la même configuration.
"multistrap" s'arrêtera avec le code d'erreur 7 s'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
"multistrap" supports an option to explicitly set the default release to use with apt:
"aptdefaultrelease". This determines which release apt will use for the base system
packages and is not the same as pinning (which relates to the use of apt after
installation). Multistrap sets the default-release to the wildcard * unless a release is
named in the "aptdefaultrelease" field. Any release specified here must also be defined in
a stanza referenced in the bootstrap list or apt will fail.
To install a specific version of a package from a newer release than the one specified as
default, "explicitsuite" must also be set to true if the package exists at any version in
the default release. Also, any packages upon which that package has a strict dependency
(i.e. = rather than >=) must also be explicitly added to the packages line in the stanza
for the desired version, even though that package does not need to be listed to get it
from the default release. This is typical apt behaviour and is not a bug in multistrap.
The combination of default release, explicit suite and apt preferences can quickly become
complex and bugs can be very hard to identify. "multistrap" always outputs the complete
apt command line, so test this command yourself (using the files written out by
"multistrap") to see what is going on. Remember that all dependency resolution and all the
logic to determine which version of a specific package gets installed in your "multistrap"
chroot is entirely down to apt and all "multistrap" can do is pass files and command line
options to apt.
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.
De même, quand vous indiquez des paquets à prendre depuis une version spécifique de la
distribution, apt essaie 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, indiquer 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.
La manipulation de suite explicite peut être difficile à faire fonctionner. En général, il
vaut mieux créer un petit chroot bootstrap de l'architecture native, puis faire un chroot
dedans, ajouter les bonnes sources apt pour trouver les commandes nécessaires et
suffisantes pour obtenir le mélange de paquets adéquat. Évitez d'indiquer des versions
explicites pour contourner les problèmes, travaillez avec les suites uniquement.
L'épinglage avec l'utilisation d'un fichier de préférences apt peut être utile ici,
consultez préférences apt.
Préférences apt
Si un fichier adéquat est indiqué dans l'option aptpreferences de la section General du
fichier de configuration, il sera copié dans le répertoire des préférences de apt du
bootstrap avant d'utiliser apt.
Quand un fichier de préférences apt est fourni, le comportement "Default-Release" de
"multistrap" est désactivé.
Comme avec d'autres scripts et fichiers extérieurs, le contenu du fichier de préférences
apt sort du cadre de ce manuel. "multistrap" ne tente pas de vérifier le fichier fourni
mais s'assure juste qu'il peut être lu.
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-délivré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 apparaît avec "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" ni "additional" ne devraient être considérés mieux 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
Files which do not exist or which cannot be opened will be silently ignored. Check the
results of the parsing using the "--simulate" option to "multistrap". The preseeding files
will be copied to a preseed directory in /tmp inside the rootfs.
To use the preseeding, add a section to the configscript.sh, prior to any calls to dpkg
--configure -a. e.g. :
#!/bin/sh
set -e
export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true
export LC_ALL=C LANGUAGE=C LANG=C
if [ -d /tmp/preseeds/ ]; then
for file in `ls -1 /tmp/preseeds/*`; do
debconf-set-selections $file
done
fi
dpkg --configure -a
Détournements
If a hook directory (hookdir=) is specified in the General section of the "multistrap"
configuration file, the hook scripts which are executable will be run from outside the
multistrap directory at the following stages:
Déclencheurs téléchargés
Exécutés avant le démarrage du dépaquetage, 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és juste avant que l'archive (« tarball ») soit créée ou que "multistrap" quitte
s'il n'est pas configuré pour la créer.
Completion scripts are executable scripts in the specified hook directory with a filename
beginning with 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. Les déclencheurs ne pouvant être résolus en
utilisant realpath ou qui ne sont pas exécutables seront ignorés.
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" signalera 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 sorties - 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 complexe, des bogues s'insinuent dans le paquet. Veuillez
signaler 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-coller (« pastebin ») et indiquer l'adresse dans votre message.
Prise en charge multiarchitecture
La prise en charge multiarchitecture est expérimentale — veuillez signaler les problèmes
et soumettre des rapports de bogues avec tous les détails de votre installation, le
fichier de configuration complet de multistrap et les erreurs signalées.
"multistrap" outrepasse la prise en charge multiarchitecture du système externe pour qu'un
système prêt pour le multiarchitecture puisse toujours créer un chroot non
multiarchitecture depuis des dépôts qui ne permettent pas d'utiliser toutes les
architectures compatibles avec le dpkg externe.
Si multiarch est activé au sein du chroot multistrap, "multistrap" écrit la liste dans
/var/lib/dpkg/arch à l'intérieur du chroot.
Pour les architectures multiples, veuillez indiquer l'option une fois et utilisez une
liste séparée par des espaces pour la liste des architectures. Assurez-vous d'avoir inclus
ce qui constituera l'architecture hôte du chroot.
Consultez 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