J'ai un petit problème, et j'aimerais votre avis sur comment le résoudre. Je vous propose également une solution que j'ai réalisée (mais avec certaines limitations). Mon cas d'utilisation est simple. Je viens de cloner un projet depuis son dépôt Git, je l'ai compilé, et j'aimerais éviter de faire un make install bien crade.
Pourquoi c'est crade ? Déjà parce que tous les projets ne fournissent pas toujours un make uninstall, et qu'ensuite, il n'y a aucune façon de bien vérifier que le make uninstall enlève bien tout. Donc je ne le fais simplement pas.
Ce que je fais, c'est un make DESTDIR=$PWD/root install qui va tout m'installer dans root/usr/local/.... Et j'aimerais exécuter ces fichiers. Sauf que comme l'application n'est pas relocalisable, ce n'est pas possible.
J'ai pensé qu'il serait possible avec OverlayFS + chroot d'arriver a mes fins. OverlayFS se chargerait de monter quelque part une image de mon système de fichier complet (/) ne lecture seule, et d'y inscrire un dossier $PWD/root en lecture-ecriture. Il ne reste plus qu'un chroot pour entrer dans de dossier, et le tour est joué.
C'est le rôle du projet ovroot (pour overlay chroot) qu'il est possible de trouver sur github. Mon principal problème est que OverlayFS va monter une image de ma partition racilee (/), mais pas de mes fichiers personnels (/home) ni de plein de trucs super utiles comme /run, /proc, /dev ou /sys. Cela semble être une limitation de ce que peut faire OverlayFS.
Et vous, connaissez-vous un projet qui puisse faire quelque chose de similaire ?
# Checkinstall sur debian-like
Posté par navaati . Évalué à 10.
Si tu es sur debian ou assimilé, je te conseille l'excellent checkinstall qui va surveiller le make install et créer un paquet .deb contenant le logiciel installé. Ainsi tu pourra désinstaller le soft avec apt.
Sur les systèmes type archlinux ou gentoo les recettes de création de paquets (PKGBUILDs, ebuilds) sont tellement simple à écrire (si on tiens pas à faire propre, mais ici la recette reste chez toi) que la meilleure solution est sans doute de t'en faire une pour ton soft, la recette n'étant qu'un peu de boilerplate autour du configure - make - make install.
Sous distro rpm, j'en sais rien désolé :/.
[^] # Re: Checkinstall sur debian-like
Posté par khivapia . Évalué à 7.
Sous distro rpm, j'en sais rien désolé :/.
checkinstall fonctionnait bien sous feu Mandrake 10.1, pas de raison que ça ait changé depuis.
Au pire un checkinstall qui crée un deb, puis un alien pour le transformer en .rpm. Ça ne gère de toutes façons pas les dépendances correctement, mais ça évitera les résidus d'installation.
# Conteneur léger tel que Docker
Posté par Tangi Colin . Évalué à 5. Dernière modification le 06 janvier 2015 à 17:04.
Docker peut répondre à ta problématique.
[^] # Re: Conteneur léger tel que Docker
Posté par cosmocat . Évalué à 4.
C'est pour vendre ta solution que tu met "Conteneur léger" dans le titre?
Car, si je ne m'abuse, un conteneur, c'est peut-être léger quand on le compare à une VM (et on peut aisément le faire car le cas d'utilisation est de répondre aux même problématiques), mais c'est absolument pas léger dans l'absolu!
Ton conteneur contient toutes les dépendances sous-jacentes (excepté le noyau), donc il y a un grande chance que ton conteneur fasse dans les 100Mo (ordre de grandeur si il est pas fait aux petite oignons.)
Et surtout en mémoire, il prendra un peu de place, au mieux si tu as la même version des binaires dans en dehors du conteneur (et que le noyau fait de la dé-duplication de pages mémoire) et au pire, ben toutes les libs sont différentes et tu montes tout en mémoire.
Tout ça pour dire, qu'il vaut mieux ne pas utiliser "conteneur" avec "léger" ;) (sauf si tu compares avec les VMs)
[^] # Re: Conteneur léger tel que Docker
Posté par Tangi Colin . Évalué à 6. Dernière modification le 06 janvier 2015 à 21:16.
Premier point, je n'ai rien à vendre. C'est juste une technologie qui je connais et avec lequel je m'amuse pas mal, point.
Mais 100Mo c'est vraiment si lourd ?
Y a des conteneur qui font bien moins que 100Mo tout dépend ce que tu veut faire.
Si tu fais un
tar cv --files-from /dev/null | docker import - scratchtu te retrouve avec un conteneur qui a un overhead null. Pour des programmes compilés statiquement (trivial a faire pour des programmes écrit en go si tu utilise le compilateur cgo par exemple) tu as juste ton programme et rien de plus. Pas mal non ?
Si tu veux avoir des librairies dynamique rien ne t’empêche de les avoir sur ton OS ou dans un autre conteneur et de faire des mount-bind (docker volume).
Tu as aussi des images busybox qui font ~50Mo et l'image debian de base fait 83Mo.
Sachant qu'en plus avec docker tu utilise généralement soit aufs (unionfs) ou btrfs(copy on write) comme système de fichier tu peux pas vraiment dire qu'il y a un overhead, t'as 10 images basé sur la debian base tu te retrouve qu'avec un seul fois les 83Mo (copy on write ou unionfs).
Donc si c'est léger en taille. (Après en ressource kernel avec tout les namespaces crée c'est une autre histoire).
Et puis l'idée du titre c'était de parler de conteneur léger. Y a pas que docker, y a lmctfy de chez google , rocket de chez coreos, lxc etc… Le principe de l'isolation n'a pas été inventé chez docker.
[^] # Re: Conteneur léger tel que Docker
Posté par reynum (site web personnel) . Évalué à 4.
Ça dépend si on fait un retour vers le passé (on est la bonne année), en 1989 un gros disque dur faisait 100Mo et les monstres de guerre avaient 8Mo de RAM.
En 2015 c'est les systèmes embarqués qui sont parfois limités en mémoire vive et ou mémoire morte.
Donc oui c'est lourd dans certains cas.
Bon soyons honnête même pour un PC bas de gamme de notre époque qui n'a "que" 4Go de RAM et 1To de Dur, cent meg c'est pas grand chose.
kentoc'h mervel eget bezan saotred
[^] # Re: Conteneur léger tel que Docker
Posté par Nico C. . Évalué à 3.
LA solution pour répondre au besoin exposé…
Docker est excellent pour le dev et le test, c'est une evidence.
# Commentaire supprimé
Posté par erdnaxeli (site web personnel) . Évalué à 2. Dernière modification le 06 janvier 2015 à 17:48.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Mon commentaire sur les commentaires supprimés sans commentaires du modérateur
Posté par barmic . Évalué à 10.
Je suis toujours dubitatif avec les messages supprimé comme ça.
J'ai aucune idée de ce qui a pu entrainer une suppression en commentaire racine par un membre de linuxfr depuis plus de 5 ans (il n'a probablement pas insulté, ni fait de la publicité par exemple).
Ça me démange toujours de savoir ce qu'il y avait avant :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Doublon supprimé à la demande de l'auteur
[^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur
Posté par ʭ ☯ . Évalué à 7. Dernière modification le 06 janvier 2015 à 19:01.
Roh même pas un complot à se mettre sous la dent?
Ceci étant, ce compte n'a rien posté dans ce journal, alors quel doublon est possible?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur
Posté par navaati . Évalué à 10.
La Cabale n'existe pas.
[^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur
Posté par Larry Cow . Évalué à 3.
La cuillère non plus.
[^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur
Posté par zurvan . Évalué à 4. Dernière modification le 07 janvier 2015 à 09:28.
Si je me souviens bien, il avait écrit un truc du genre "Docker c'est super adapté pour ton cas, edit grilled, merci à la modération de supprimer ce commentaire" (cf. le commentaire d'avant qui en avait parlé avant, du coup celui-ci faisait doublon). Bref, ça aurait été mieux de supprimer tout le commentaire, ou de le laisser dans son intégralité, si c'était pour éviter la pollution visuelle.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
[^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur
Posté par cosmocat . Évalué à 5.
En fait, je crois qu'il faut juste indiquer la raison lors de la suppression, comme tu as été obligé de le faire pour apporter la justification. Genre:
ou
Car il est vrai qu'on peut être un peu suspicieux lorsqu'on voit un tel message (mais ça n’empêchera pas ceux qui croient à la théorie du complot de crier ;) )
[^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
Techniquement actuellement, la suppression d'un commentaire par l'équipe de modération est un booléen. Pour une évolution, voir l'entrée de suivi.
[^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur
Posté par zurvan . Évalué à 3.
oui, sauf que quand le commentaire est tendancieux (genre "une distribution se crashe sur un banc de moule après avoir hurlé 'systemd aquebar'") ceux qui se souviennent vont peut-être crier à la censure, alors que si c'est un doublon supprimé à la demande du posteur initial, ceux qui s'en souviendront sauront que c'était anodin et bien loin des malversation de la cabale (qui n'existe pas).
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Mon commentaire sur les commentaires supprimés sans commentaires du modérateur
Posté par barmic . Évalué à 7.
Mon message manquait probablement de smiley. Je ne cherchais pas le moins du monde à créer un polémique (si si je vous jure) et je ne remet pas du tout en question la pertinence de la modération (qui est très légère sur dlfp).
Je suis juste très curieux rien de plus :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
# proot
Posté par Dreammm . Évalué à 10.
Non, ce n'est pas un bruit gastrique suite aux bacchanales récentes. Proot est un outil regroupant les fonctionnalités d'un
chrootet d'unmount --bind.Exactement ce que tu veux donc. Joyeux noël, en avance de 359 jours. Remarque, on n'a jamais été aussi près de Noël en 2015.
[^] # Re: proot
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Il me semble que schroot fait cela aussi
# --prefix ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Salut,
Corrige moi si je me trompe, mais ta problématique est simplement d'installer un programme auto-compilé, que tu comptes vraiment utiliser (et pas juste tester)?
Parce que le sandbox, c'est plus pour des tests, par exemple pour sécuriser tes données si tu n'as pas entièrement confiance au programme exécuté, ou si c'est une version de dév un peu instable, ou que sais-je encore. Mais si ta problématique est uniquement que tu veux pas faire d'install crade, ça me paraît disproportionné.
Si ton programme utilise les autotools, il suffit de mettre l'option --prefix au script configure:
Les autres systèmes de compilation ont (tous ceux qui se respecte, à ma connaissance) aussi un moyen de spécifier le préfixe d'installation, par exemple lors de la phase cmake, etc.
$HOME/.local est un préfixe assez classique pour installer des logiciels pour ton user seulement (mais ça mélangera les divers logiciels si tu en installes d'autres avec ce même préfixe). Tu n'as même pas besoin d'être root pour le
make install(en fait, de manière général, je déconseille d'installer quoi que ce soit d'auto-compilé en root, sauf si vous êtes vraiment sûr de vous).Sinon souvent on va installer dans /opt/nom-du-logiciel/ ou quoi que tu veuilles. Il suffit juste de bien mettre à jour la variable d'environnement $PATH.
Par exemple dans ton ~/.bashrc:
Ensuite quand tu veux désinstaller, si tu as utilisé un préfixe unique avec aucun autre logiciel installé dedans, tu peux juste effacer tout le répertoire.
Note que DESTDIR fait quelque chose de similaire, sauf que ce n'est absolument pas fait pour une installation finale. C'est plutôt fait pour créer votre arborescence, préfixe compris, dans un répertoire pour ensuite le déplacer ailleurs, cette fois au bon préfixe. L'utilisation la plus commune est la création de paquet, pour une utilisation sur plusieurs machines, par exemple dans un parc informatique, ou bien pour une distribution Linux, etc.
En gros on donne à --prefix l'emplacement qui sera utilisé au final par le logiciel dans la machine cible, alors que DESTDIR n'est qu'un emplacement temporaire, en préparation du paquet, sur la machine de compilation et ne doit avoir absolument aucun impact sur l'installation finale.
En fait c'est même sujet à bug d'utiliser DESTDIR pour une installation finale. En effet, le logiciel peut potentiellement utiliser le préfixe déterminé à la configuration (qui peut alors être inclus dans les sources avant compilation); par exemple pour connaître l'emplacement de données (permettant ainsi les binaires et les données d'être dans un préfixe différent notamment).
DESTDIR par contre ne sert à rien et ne sera jamais utilisé par le logiciel final. Tu risques donc de "casser" le logiciel si ton installation repose sur l'usage de DESTDIR.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: --prefix ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je pense aussi que la solution que l'auteur cherche est --prefix, la seul option vraiment utilisé à l'usage des ./configure.
"La première sécurité est la liberté"
[^] # Re: --prefix ?
Posté par oinkoink_daotter . Évalué à 2.
Cela a aussi a quelques inconvénients, au minium
- le bricolage du path,
- mais aussi le ld.so.conf puis ldconfig et/ou l'équivalent en variable d'environnement (?),
- et enfin, la séparation totale du système, donc les fichiers pour etc, var, run, arrivent dans des endroits bizarres dont il faut tenir compte, par exemple pour logrotate si besoin.
Je dis pas que c'est mal, hein. Juste que c'est rapidement très chiant.
[^] # Re: --prefix ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
Salut,
Tu as raison, mais en même temps, c'est ce que l'auteur veut: une séparation de certains logiciels du reste du système. Et je suis pas sûr que ce soit beaucoup plus chiant que les alternatives proposées (sandboxing!).
Et si on utilise toujours le même préfixe alternatif, alors on n'a pas à mettre a jour les variables d'environnement 100 fois, juste la première fois. En fait tout dépend vraiment du type d'utilisation que l'auteur du journal avait en vue, ce qui n'est pas très clair pour moi. Si c'est juste pour utiliser un logiciel stable régulièrement et que la seule chose qu'elle souhaitait éviter était de mélanger des données et binaires installés manuellement avec le système principal (ce qui serait en effet une très mauvaise idée), alors un --prefix est je pense le plus simple.
Ensuite comme quelqu'un propose plus bas, y a aussi la solution de faire un paquet pour le système cible, ce qui permet à la fois d'installer avec le reste du système (et donc de n'avoir aucune variable à mettre à jour) tout en ayant une (dés)installation propre.
Par contre ça implique de savoir rapidement faire un paquet (là encore ça va, c'est comme tout, ça s'apprend; mais ça reste tout de même un point de complexité supplémentaire par rapport à un simple --prefix), mais surtout ça rend les modifications plus dur, ce qui est embêtant si le but était aussi de pouvoir modifier le programme (ce qui est souvent la raison pour laquelle je compile moi-même certains logiciels).
Bien sûr, si ce n'est pas le cas de Mildred et qu'elle n'a aucune intention de modifier le logiciel, alors c'est aussi une alternative intéressante.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Ma solution
Posté par Pseudo007 . Évalué à 2.
Pour ce problème, je me crée à la va-vite un paquet rpm. Je peux tester l'installation et la désinstallation (et le programme) avec un chroot créé par mock (qui fait aussi la compilation du paquet).
C'est juste ma solution.
Si j'ai pas rpm, "./configure --prefix=…." comme le mentionne quelqu'un d'autre.
[^] # Re: Ma solution
Posté par podoc . Évalué à 1.
Bonjour,
mon experience personnelle m'a appris qu'il est bien de spécifié aussi l'option exec_prefix
"./configure --prefix= --exec-prefix="
Souvent le premier suffit mais parfois il faut les 2 .
# Stow
Posté par hocwp (site web personnel) . Évalué à 5.
Si tu n'as pas besoin d'isoler ton programme des autres, tu peux utiliser stow. Il permet d'installer un programme dans un répertoire et de créer des liens dans /usr/local pour qu'il fonctionne correctement.
Sinon des fois, j'utilise un truc maison.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.