Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Quand vient le jour du "make uninstall".

18 réponses
Avatar
Étienne Labaume
Bonjour à tous, et bonne année !

Je cherche une méthode passe-partout pour désinstaller un programme
qui utilise automake/autoconf pour se compiler puis s'installer. Je
pourrais garder le paquet source, le décompresser, relancer ./configure
avec les mêmes options, puis "make uninstall". Mais quand le tarball est
gros parce que le programme utilise des fichiers volumineux, je trouve
que ça prends de l'espace disque pour rien. L'exemple qui me conduit à
poster, c'est Celestia (http://celestia.sourceforge.net/), un simulateur
spatial, qui regorge d'images (déjà compressées) et de fichiers de
données.

J'ai donc essayé de créer une arborescence du tarball qui ne contienne
que les fichiers utile à la désinstallation, à grand coups de "find",
mais je n'arrive pas à trouver de règle portable d'un tarball à l'autre
pour garder tout ce qui (et seulement ce qui) est utile à la
désintallation.

Comment faites-vous dans un tel cas ? Y a-t'il une méthode universelle ?
Dois-ja passer par le (long) processus de la création de package pour
chaque système que j'utilise ? J'ai regardé un peu la doc d'autoconf et
automake, mais ce genre de considération n'y est pas couvert,
visiblement.

Merci de votre intérêt pour ma question.

--
Tinou

10 réponses

1 2
Avatar
Étienne Labaume
Le 01 Jan 2006 13:38:36 GMT, Étienne nous disait:

Bonjour à tous, et bonne année !


Bon, comme d'hab, je trouve la réponse à ma question une fois que je
l'ai postée. Donc je réponds à moi-même, et je donne la solution pour
les ceusses que ça intéresse.

Comment faites-vous dans un tel cas ? Y a-t'il une méthode universelle ?


Il existe un programme de création rapide de packages pour Linux qui
s'appelle checkinstall. En lançant "make install" par son intermédiaire,
on créé un package pour Slackware, ou Debian, ou les RPM-friendly. Et
checkinstall utilise un sous-programme (installwatch) qui guette les
appels système lancés par le "make install". On peut se contenter
d'utiliser la sortie de ce script pour savoir quels sont les fichiers
installés sur le système:

$ installwatch -o rapport.log make install

Le fichier rapport.log peut facilement être converti via sed ou awk en
un shellscript qui supprimmera chaque fichier installé. Installwatch a
l'air de fonctionner sur tous les systèmes dont les binaires sont au
format ELF.

--
Tinou

Avatar
Nicolas George
Étienne Labaume wrote in message
<43b7db5b$0$12531$:
Comment faites-vous dans un tel cas ?


Personnellement, j'installe chaque programme (ou groupe de programmes)
séparément dans un sous-répertoire de /opt/, et je mets des liens
symboliques dans /usr/local. Pour supprimer, un rm -rf puis une suppression
des liens mots suffit.

Il faut noter que les makefiles produits par les autotools ont, en plus de
la règle uninstall, le paramètre DESTDIR : si l'on tape « make
DESTDIR=/tmp/install install », tout se retrouve installé dans /tmp/install/
(tout est décalé : il y aura un /tmp/install/usr/local/, etc.). Ainsi, il
devient possible de faire le make install avec des droits restreints, et
d'utiliser les droits d'écriture sur le répertoire d'installation uniquement
pour un cp -r. Et au passage, il est très facile de récupérer la liste
exacte des fichiers installés.

Une autre possibilité qui n'a rien à voir, c'est de noter la sortie de
« make -n uninstall », et de la transformer en script shell.

Avatar
Doug713705
Le Dimanche 1 Janvier 2006 16:59, Étienne Labaume s'est exprimé de la sorte
sur fr.comp.os.unix :

Il existe un programme de création rapide de packages pour Linux qui
s'appelle checkinstall. En lançant "make install" par son intermédiaire,
on créé un package pour Slackware, ou Debian, ou les RPM-friendly. Et
checkinstall utilise un sous-programme (installwatch) qui guette les
appels système lancés par le "make install".




Attention, j'ai eu quelques cas où checkinstall finissait par se perdre
(notament sur les gros projets qui compilent leur propres jeux de
librairies). Dans ces cas là, le checkinstall produit bien un paquet mais
qui une fois installé n'est pas complet ou mal organisé (en fait je ne sais
pas trop) mais toujours est il que le package n'est pas utilisable (alors
que la version compilée à ma main avec les mêmes paramètres est utilisable)

Maintenant il y'a peut-être des détails que je n'ai pas bien compris mais
aujourd'hui je me méfie de checkinstall (qui reste excellent sur les petits
projets).

--
@+
Doug [Linux user #307925] - Slackware RuleZ ;-)
[Pourquoi t'es qui, qu'est ce que tu fais par où ?]
-- Pour me contacter enlever no-spam (2X) --

Avatar
R12y
[check install]
[check install]



Mais pourquoi ne pas apprendre à faire un package binaire pour le système
en question, et puis c'est fait?
Entre apprendre à utilisait un utilitaire pour désinstaller, et apprendre
à faire des packages, moi je trouve que l'effort est quesiment le même à
fournir...

--
Telephone portable "intelligent" (SmartPhone) GSM, GPRS,...
Il est sous Linux, ne coute pas trop cher,...
http://www.it2l.com/product_info.php?cPath‘&products_idE6


Avatar
Croco
Le 01-01-2006, R12y a écrit :
[check install]
[check install]



Mais pourquoi ne pas apprendre à faire un package binaire pour le système
en question, et puis c'est fait?
Entre apprendre à utilisait un utilitaire pour désinstaller, et apprendre
à faire des packages, moi je trouve que l'effort est quesiment le même à
fournir...


Ben la différence est que "make uninstall" est multi-plateforme (a
priori toutes celles supportées par le makefile s'il est bien fait)
alors que le "package" binaire est mono-plateforme. Donc si l'effort est
"quasiment le même à fournir", autant apprendre à faire un "make
uninstall" propre...

Croco



Avatar
Doug713705
Le Dimanche 1 Janvier 2006 19:10, R12y s'est exprimé de la sorte sur
fr.comp.os.unix :

Mais pourquoi ne pas apprendre à faire un package binaire pour le système
en question, et puis c'est fait?


Parce que je n'aime pas les packages binaires.

Tous les gouts sont dans la nature...
--
@+
Doug [Linux user #307925] - Slackware RuleZ ;-)
[Pourquoi t'es qui, qu'est ce que tu fais par où ?]
-- Pour me contacter enlever no-spam (2X) --

Avatar
Pascal Bourguignon
Étienne Labaume writes:
Je cherche une méthode passe-partout pour désinstaller un programme
[...]
Comment faites-vous dans un tel cas ?


Je ne fais pas. J'ai un /usr/local qui contient encore des fichiers
A/UX et NeXTSTEP... Quand je n'aurais plus aucune espoir de le monter
sur ma NeXTstation, peut être que je recommencerais un /usr/local à
partir de zéro juste pour linux.

Y a-t'il une méthode universelle ?


Non, pas avec make.


Dois-ja passer par le (long) processus de la création de package pour
chaque système que j'utilise ?


Oui, c'est le problème que résolvent les systèmes comme rpm, fink,
emerge, etc.


J'ai regardé un peu la doc d'autoconf et
automake, mais ce genre de considération n'y est pas couvert,
visiblement.


Il faut collecter la liste des fichiers installés au moment de
l'installation. Ça peut se faire relativement automatiquement en
effectuant l'installation dans un environnement chrooté et en
comparant avant et après. Ça revient à réimplémenter un système de
gestion des paquets comme rpm et co.

--
__Pascal Bourguignon__ http://www.informatimago.com/
Litter box not here.
You must have moved it again.
I'll poop in the sink.

Avatar
R12y
Mais pourquoi ne pas apprendre à faire un package binaire pour le système
en question, et puis c'est fait?
Parce que je n'aime pas les packages binaires.

Tous les gouts sont dans la nature...


ça ne te dérange pas d'avoir un environnement de développement sur une
machine de production? parceque pour compiler, faut avoir installé le
compilateur et les headers, au moins. Pourtant moins on en installe mieux
c'est. Non?

--
Telephone portable "intelligent" (SmartPhone) GSM, GPRS,...
Il est sous Linux, ne coute pas trop cher,...
http://www.it2l.com/product_info.php?cPath‘&products_idE6


Avatar
Croco
Le 01-01-2006, R12y a écrit :
Mais pourquoi ne pas apprendre à faire un package binaire pour le système
en question, et puis c'est fait?
Parce que je n'aime pas les packages binaires.

Tous les gouts sont dans la nature...


ça ne te dérange pas d'avoir un environnement de développement sur une
machine de production?


Ben si par "environnement de développement" tu entends Eclipse, KDevelop
et des paquets en -devel, alors oui, cela n'a rien à faire sur un
serveur en prod.

parceque pour compiler, faut avoir installé le compilateur et les
headers, au moins.


Perso, j'appelle plus cela un "environnement de compilation" qu'un
"environnement de développement" (je sais, cela joue un peu sur les
mots, mais...
En tout cas, le compilteur fait partie de la base de tout les BSD et des
systèmes reposant sur pkgsrc ou les ports, et cela ne semble pas poser
de problème majers.

Pourtant moins on en installe mieux c'est. Non?


Oui, mais il faut tout de même disposer du strict nécessaire...



Avatar
R12y
Dois-ja passer par le (long) processus de la création de package pour
chaque système que j'utilise ?
Oui, c'est le problème que résolvent les systèmes comme rpm, fink,

emerge, etc.


Mais y en a qui disent que c'est pas multi plateforme, et d'autes qui
n'aiment pas les packages binaires, tout court.
Finalement, il y a une diversité de point de vues sur la question.

--
Telephone portable "intelligent" (SmartPhone) GSM, GPRS,...
Il est sous Linux, ne coute pas trop cher,...
http://www.it2l.com/product_info.php?cPath‘&products_idE6


1 2