chroot, mais pas vraiment chroot

[Emmanuel Deloget]

Bonjour tout le monde,

Alors que je fait des recherches pour un petit projet personnel, je me heurte à la barrière de ma propre incompétence. Laissez-moi vous expliquer tout ça.

Supposons que j'ai un package sous la forme de code source configurable grâce aux scripts générés par les autotools. Je lance la configuration et la compilation :

$ ...home > mkdir build && cd build
$ ...build > ../configure
$ ...build > make

J'ai généré plusieurs librairies dynamiques, des librairies statiques et des programmes grâce à ce package fictif. Maintenant, j'installe le tout

$ ...build > make install

L'installation crée des fichiers de configuration, les copie, copie des librairies en changeant leur nom, et fait toute sorte de chose difficilement reproductible à la main.

Bien. Pas mal.

Maintenant, je souhaite récupérer l'ensemble des fichiers générés et les mettre dans un répertoire "deb" afin de créer un package DEBIAN que je pourrais déployer facilement sur tous les postes dont j'ai la responsabilité.

A l'heure actuelle, la seule solution est de

1) regarder tout ce qu'a fait "make install"
2) récupérer les fichiers générés
3) reproduire dans deb l'architecture des répertoire nécessaires
4) copier tous les fichiers créés/copiés/liés par "make install" dans les sous-répertoires de deb.

C'est un point long - et générateur potentiel d'erreurs...

Une autre solution est de passer en paramètre de "make install" la liste des répertoires qui seront utilisés pour l'install :

$ ...build > make install prefix='./deb/usr/bin' execprefix='./deb/usr/bin' (etc)

Un peu long, car il faut spécifier tous les répertoires un a un, sans pour autant être sûr qu'on ne va pas en oublier (exemple: usbdropdir='...' pour le driver ccid). Pire, si les makefiles du projet sont mal conçus, ils peuvent faire référence à un chemin en dur, et là je n'ai aucun moyen de le changer).

Bref, aucune de ces deux solutions n'est optimale.

Une troisième solution pourrait être envisagée - elle aurait le mérite de fonctionner exactement comme prévu et de ne rien laisser au hasard. Supposons pour celà que j'ai un environnement chrooté dans ./deb/. Je peux faire

$ ...build > chroot ./deb/ make install

Ca serait presque l'idéal. Le problème est que pour que ça marche, il faut que deb contiennent l'ensemble des programmes et fichiers qui seront utilisés pendant l'exécution de make install. Hors, ce n'est pas le cas. D'une part je ne vais pas m'amuser à copier l'ensemble des programme qui sont utilisés pendant ce process (make, sh, libtool, cp, ...). D'autre part, même si je le faisait, je me retrouverais dans la même situation que ci-dessus : il faudrait que je retrouve mes fichiers dans tout ce système chrooté.

Conclusion, il me faudrait un programme qui réagit vaguement comme chroot (en ce qui concerne l'écriture de fichiers), mais qui laisse passer tout les autres accès fichier comme si le programme n'était pas appelé. Exemple : supposons que j'ai un script install.sh ressemblant à ceci :

Code :

1
2
3
4
5
6
7
8
9
10
11
 
#!/bin/sh
 
# mkdir, cp, ln, ... sont dans /bin
mkdir -p /etc/mon_package/
mkdir -p /usr/local/lib/
cp mon_fichier.conf /etc/mon_package/mon_fichier.conf
cp libmon_package.so.0.0.0 /usr/local/lib/libmon_package.so.1.0
cd /usr/local/lib
ln -s libmon_package.so.1.0 libmon_package.so
cd -

En exécutant

$ ...build > ./install.sh

Le script se comporte normallement et va copier les éléments dans /etc/mon_package et /usr/local/lib.

Maintenant, en éxécutant

$ ...build > presque_chroot deb/ ./install.sh

Le script va se comporter
1) (en terme d'écriture) comme si deb/ était / (et donc créer les répertoires et fichiers dans deb/etc/mon_package et deb/usr/local/lib)
2) (en terme de lecture) comme si / était / (et donc trouver sans aucun problème /bin/cp, ... sans qu'on est besoin de monter un environnement chrooté dans deb/).

Mes questions :
* J'ai le préssentiment qu'un tel programme n'existe pas aujourd'hui. Si c'est la cas, pouvez vous me pointer dessus ?
* Si ce n'est pas le cas, existe-t-il des alternatives plausibles permettant un comportement similaire (y compris à base de chroot, si une telle chose est possible)
* Le cas échéant, quelqu'un a-t-il une idée de comment je peux réaliser un tel logiciel ? J'ai l'intuition que je peux probablement repartir du code source de fakeroot (puisque globalement, l'idée de fonctionnement est la même : changer le comportement des appels systèmes).

Merci de votre aide - et n'hésitez pas à me poser des questions si je n'ai pas été assez clair.

[tonton fred]

Salut,

Code :

./configure --prefix=./deb

ne te suffit pas ?

[Emmanuel Deloget]

Envoyé par tonton fred

Salut,

Code :

./configure --prefix=./deb

ne te suffit pas ?

Nope. J'aurais aimé, mais même si ça réponds à la question dans 90% dans des cas, il reste quelques cas ou ça ne fonctionne pas (notamment les cas ou le produit généré utilise comme répertoire cible des répertoires provenant d'une autre source que le makefile (exemple : une valeur obtenue via pkg-config)). Autre problème de cette technique, c'est que je peut souhaiter utiliser prefix pour spécifier le répertoire d'installation que je souhaite réellement (/usr au lieu de /usr/local); le fait de l'utiliser de la manière que tu propose ne me permet pas de changer quoi que ce soit.

J'explique mon problème de manière un plus plus précise : a l'heure actuelle, je maintiens un logiciel non-oss pour Linux, et ce logiciel est distribué sous la forme de packages sur les différentes distributions. Différentes distribution, ça veut dire différent chemins d'installation qui sont pour une certaine partie précisée grâce aux options de configure, et pour un autre partie récupérée de programmes externes. La création des packages est un tâche difficile et génératrice d'erreurs - d'autant que j'ai 8 packages différents à créer).

A l'heure actuelle, je suis en train de réaliser un script qui récupère et analyse la sortie de make -n.L'idée c'est de repérer les commandes, de les modifier et de les ré-exécuter. Ce n'est pas d'une simplicité extrême...

[tonton fred]

Effectivement c'est pas d'une grande simplicité... Il m'arrive d'avoir le problème inverse : utilise un package linux sous freebsd.
Quand j'ai besoin de me créer une arborescence exotique j'utilise des systèmes de fichiers "empilables" (stackable fs, je trouve pas de meilleure traduction): nullfs et unionfs. http://en.wikipedia.org/wiki/UnionFS existe sous linux d'après la wikipedia, et nullfs n'est qu'une union qui cache la couche inférieure. Bon par contre c'est pas vraiment léger a mettre en place mais après c'est d'une souplesse a toute épreuve... A toi de voir si c'est plus simple que de scripter le tout.

[Emmanuel Deloget]

A cause de toi, j'ai suisi les liens sur Wikipedia, et je suis tombé sur le UNIX-HATERS Handbook.

J'ai déjà perdu une bonne partie de la journée...

Je pense que je vais m'orienter vers l'écriture d'un programme...

[pitipoisson]

Bonjour,

Il existe des outils pour faire ça. Je pense en particulier à checkinstall

Code :

sudo checkinstall -D make install

Tu peux préciser les dépendances avec l'option --requires="<liste_séparé_par_vigules>".

Après, je crois qu'il existe des manières de faire des paquets plus "officiels" à partir de dh_make, debuild, etc. (comme ça t'as quelques mots clefs pour trouver des tutos).

[Emmanuel Deloget]

Envoyé par pitipoisson

Bonjour,

Il existe des outils pour faire ça. Je pense en particulier à checkinstall

Code :

sudo checkinstall -D make install

Tu peux préciser les dépendances avec l'option --requires="<liste_séparé_par_vigules>".

Après, je crois qu'il existe des manières de faire des paquets plus "officiels" à partir de dh_make, debuild, etc. (comme ça t'as quelques mots clefs pour trouver des tutos).

checkinstall est une bonne base pour faire ce que je veux. Je vais tenter de l'exploiter...