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.
Le Sun, 1 Jan 2006 20:28:57 +0000 (UTC), Croco nous disait:
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.
$ which gcc gcc: Command not found. $ which cc cc: Command not found. $ uname -l OpenBSD
Pourtant moins on en installe mieux c'est. Non?
Oui, mais il faut tout de même disposer du strict nécessaire...
$ which tar /bin/tar $ which gzip /usr/bin/gzip
-- Tinou
Le Sun, 1 Jan 2006 20:28:57 +0000 (UTC), Croco nous disait:
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.
$ which gcc
gcc: Command not found.
$ which cc
cc: Command not found.
$ uname -l
OpenBSD
Pourtant moins on en installe mieux c'est. Non?
Oui, mais il faut tout de même disposer du strict nécessaire...
Le Sun, 1 Jan 2006 20:28:57 +0000 (UTC), Croco nous disait:
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.
$ which gcc gcc: Command not found. $ which cc cc: Command not found. $ uname -l OpenBSD
Pourtant moins on en installe mieux c'est. Non?
Oui, mais il faut tout de même disposer du strict nécessaire...
$ which tar /bin/tar $ which gzip /usr/bin/gzip
-- Tinou
Étienne Labaume
Le Sun, 01 Jan 2006 19:10:55 +0100, R12y nous disait:
[check install]
Tout d'abord, mes propos ne s'appliquent qu'à installwatch, et pas à checkinstall.
Mais pourquoi ne pas apprendre à faire un package binaire pour le système en question, et puis c'est fait?
Parce que c'est plus long quand il faut le faire pour trois ou quatre systèmes de package différents. Parce que c'est plus long, tout court (j'ai essayé quelques créations de package Debian). Parce que je cherche quelque chose de portable (Linux, BSD, Solaris ...). Parce que c'est un bon compromis entre légèreté et fiabilité. Parce que certains jours, on est amené à utiliser une alternative, pour des tas de raisons.
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...
Là, l'utilitaire pour désinstaller, c'est rm(1). Pas dur à apprendre.
-- Tinou
Le Sun, 01 Jan 2006 19:10:55 +0100, R12y nous disait:
[check install]
Tout d'abord, mes propos ne s'appliquent qu'à installwatch, et pas
à checkinstall.
Mais pourquoi ne pas apprendre à faire un package binaire pour le système
en question, et puis c'est fait?
Parce que c'est plus long quand il faut le faire pour trois ou quatre
systèmes de package différents. Parce que c'est plus long, tout court
(j'ai essayé quelques créations de package Debian). Parce que je cherche
quelque chose de portable (Linux, BSD, Solaris ...). Parce que c'est un
bon compromis entre légèreté et fiabilité. Parce que certains jours, on
est amené à utiliser une alternative, pour des tas de raisons.
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...
Là, l'utilitaire pour désinstaller, c'est rm(1). Pas dur à apprendre.
Le Sun, 01 Jan 2006 19:10:55 +0100, R12y nous disait:
[check install]
Tout d'abord, mes propos ne s'appliquent qu'à installwatch, et pas à checkinstall.
Mais pourquoi ne pas apprendre à faire un package binaire pour le système en question, et puis c'est fait?
Parce que c'est plus long quand il faut le faire pour trois ou quatre systèmes de package différents. Parce que c'est plus long, tout court (j'ai essayé quelques créations de package Debian). Parce que je cherche quelque chose de portable (Linux, BSD, Solaris ...). Parce que c'est un bon compromis entre légèreté et fiabilité. Parce que certains jours, on est amené à utiliser une alternative, pour des tas de raisons.
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...
Là, l'utilitaire pour désinstaller, c'est rm(1). Pas dur à apprendre.
-- Tinou
Croco
Le 01-01-2006, Étienne Labaume a écrit :
Le Sun, 1 Jan 2006 20:28:57 +0000 (UTC), Croco nous disait:
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.
$ which gcc gcc: Command not found. $ which cc cc: Command not found. $ uname -l OpenBSD
Ah oui, j'oubliais qu'OpenBSD était presque toujours un cas à part... En tout cas, c'est le cas pour NetBSD et FreeBSD, au moins.
% which gcc /usr/bin/gcc % uname FreeBSD
% which gcc /usr/bin/gcc % uname NetBSD
Croco
Le 01-01-2006, Étienne Labaume <elabjoseph21@numericable.fr> a écrit :
Le Sun, 1 Jan 2006 20:28:57 +0000 (UTC), Croco nous disait:
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.
$ which gcc
gcc: Command not found.
$ which cc
cc: Command not found.
$ uname -l
OpenBSD
Ah oui, j'oubliais qu'OpenBSD était presque toujours un cas à part...
En tout cas, c'est le cas pour NetBSD et FreeBSD, au moins.
Le Sun, 1 Jan 2006 20:28:57 +0000 (UTC), Croco nous disait:
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.
$ which gcc gcc: Command not found. $ which cc cc: Command not found. $ uname -l OpenBSD
Ah oui, j'oubliais qu'OpenBSD était presque toujours un cas à part... En tout cas, c'est le cas pour NetBSD et FreeBSD, au moins.
% which gcc /usr/bin/gcc % uname FreeBSD
% which gcc /usr/bin/gcc % uname NetBSD
Croco
Étienne Labaume
Le Sun, 1 Jan 2006 21:27:21 +0000 (UTC), Croco nous disait:
Ah oui, j'oubliais qu'OpenBSD était presque toujours un cas à part... En tout cas, c'est le cas pour NetBSD et FreeBSD, au moins.
Si je suis bien ce qui est écrit, on n'est pas obligé d'installer de compilateur ni pour Net ni pour Free.
-- Tinou
Pascal Bourguignon
R12y writes:
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.
Ce sont des logiciels libres, on peut les utiliser dans n'importe quelle distribution. En plus, il y a des utilitaires comme alien pour transformer des package d'un système à l'autre. gentoo (emerge) installe à partir des sources par défault. Il me semble que fink aussi.
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.
Ce sont des logiciels libres, on peut les utiliser dans n'importe
quelle distribution. En plus, il y a des utilitaires comme alien pour
transformer des package d'un système à l'autre. gentoo (emerge)
installe à partir des sources par défault. Il me semble que fink
aussi.
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.
Ce sont des logiciels libres, on peut les utiliser dans n'importe quelle distribution. En plus, il y a des utilitaires comme alien pour transformer des package d'un système à l'autre. gentoo (emerge) installe à partir des sources par défault. Il me semble que fink aussi.
"This statement is false." In Lisp: (defun Q () (eq nil (Q)))
Pascal Bourguignon
R12y writes:
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?
Une machine sans compilateur n'est pas un ordinateur par définition. J'ai dit.
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?
Une machine sans compilateur n'est pas un ordinateur par définition.
J'ai dit.
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?
Une machine sans compilateur n'est pas un ordinateur par définition. J'ai dit.
"This statement is false." In Lisp: (defun Q () (eq nil (Q)))
Doug713705
Le Dimanche 1 Janvier 2006 20:32, R12y s'est exprimé de la sorte sur fr.comp.os.unix :
ça ne te dérange pas d'avoir un environnement de développement sur une machine de production?
Non, je n'ai pas de machine de production.
Toutes les utilisations 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) --
Le Dimanche 1 Janvier 2006 20:32, R12y s'est exprimé de la sorte sur
fr.comp.os.unix :
ça ne te dérange pas d'avoir un environnement de développement sur une
machine de production?
Non, je n'ai pas de machine de production.
Toutes les utilisations 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) --
Le Dimanche 1 Janvier 2006 20:32, R12y s'est exprimé de la sorte sur fr.comp.os.unix :
ça ne te dérange pas d'avoir un environnement de développement sur une machine de production?
Non, je n'ai pas de machine de production.
Toutes les utilisations 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) --
Cem
Le 01-01-2006, Étienne Labaume a écrit :
Je cherche une méthode passe-partout pour désinstaller un programme qui utilise automake/autoconf pour se compiler puis s'installer. [...] 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 ?
Je te conseille de regarder ce qui est dit du côté du projet LFS. http://www.linuxfromscratch.org/lfs/faq.html#why-not-package-management
Personnellement j'utilise une LFS depuis des années, et ce problème d'installation/désinstallation et tout simplement d'identification de la provenance d'un fichier se posait naturellement puisqu'à la base LFS ne propose pas de solution de gestion des packages.
J'ai d'abord utilisé "install-log" http://install-log.sourceforge.net/ C'est un simple programme qu'il suffit de lancer après installation d'un package par "install-log <nom_package>" et qui produit une liste des fichiers créés/modifiés dans un répertoire /var/log/install-logs en se référant à la date d'un fichier /var/install-log/.timestamp C'est relativement efficace à condition de corriger quelques petits bugs dans le produit (et notamment un assez énorme qui fait que le produit se base uniquement sur le "modify time", ce qui conduit à certains oublis; il faut aussi regarder le "change time" puisque le package peut installer des fichiers relativement anciens sans les modifier - patch à ta disposition si tu veux essayer le produit).
Solution similaire: ce simple script http://linuxfromscratch.org/~gerard/log-install imaginé par le créateur de LFS.
Aujourd'hui, j'utilise une autre méthode appelée "More Control and Package Management using Package Users" http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt Elle consiste à installer les programmes, non plus sous root mais sous un "Package User". Dès lors, il est très simple de repérer un fichier installé pour un package puisqu'il le user et/ou le groupe du fichier est le nom du package. J'aime d'autant mieux cette méthode qu'elle me semble aussi beaucoup plus "secure". Qu'y a-t-il en effet de moins sécurisant que de faire un "make install" sous root, permettant l'installation sans précaution de tout et n'importe quoi (et qui ouvre notamment la possibilité de laisser écraser le fichier d'un package par un autre package, ou d'installer des programmes "setuid root" qui peuvent se révéler dangereux). -- Cdlt Cem
Le 01-01-2006, Étienne Labaume <elabjoseph21@numericable.fr> a écrit :
Je cherche une méthode passe-partout pour désinstaller un programme
qui utilise automake/autoconf pour se compiler puis s'installer.
[...]
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 ?
Je te conseille de regarder ce qui est dit du côté du projet LFS.
http://www.linuxfromscratch.org/lfs/faq.html#why-not-package-management
Personnellement j'utilise une LFS depuis des années, et ce problème
d'installation/désinstallation et tout simplement d'identification
de la provenance d'un fichier se posait naturellement puisqu'à la base
LFS ne propose pas de solution de gestion des packages.
J'ai d'abord utilisé "install-log"
http://install-log.sourceforge.net/
C'est un simple programme qu'il suffit de lancer après installation
d'un package par "install-log <nom_package>" et qui produit une liste
des fichiers créés/modifiés dans un répertoire /var/log/install-logs
en se référant à la date d'un fichier /var/install-log/.timestamp
C'est relativement efficace à condition de corriger quelques petits
bugs dans le produit (et notamment un assez énorme qui fait que le
produit se base uniquement sur le "modify time", ce qui conduit à
certains oublis; il faut aussi regarder le "change time" puisque le
package peut installer des fichiers relativement anciens sans les
modifier - patch à ta disposition si tu veux essayer le produit).
Solution similaire: ce simple script
http://linuxfromscratch.org/~gerard/log-install
imaginé par le créateur de LFS.
Aujourd'hui, j'utilise une autre méthode appelée "More Control and
Package Management using Package Users"
http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt
Elle consiste à installer les programmes, non plus sous root mais sous
un "Package User". Dès lors, il est très simple de repérer un fichier
installé pour un package puisqu'il le user et/ou le groupe du fichier
est le nom du package.
J'aime d'autant mieux cette méthode qu'elle me semble aussi beaucoup
plus "secure". Qu'y a-t-il en effet de moins sécurisant que de faire un
"make install" sous root, permettant l'installation sans précaution de
tout et n'importe quoi (et qui ouvre notamment la possibilité de laisser
écraser le fichier d'un package par un autre package, ou d'installer des
programmes "setuid root" qui peuvent se révéler dangereux).
--
Cdlt
Cem
Je cherche une méthode passe-partout pour désinstaller un programme qui utilise automake/autoconf pour se compiler puis s'installer. [...] 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 ?
Je te conseille de regarder ce qui est dit du côté du projet LFS. http://www.linuxfromscratch.org/lfs/faq.html#why-not-package-management
Personnellement j'utilise une LFS depuis des années, et ce problème d'installation/désinstallation et tout simplement d'identification de la provenance d'un fichier se posait naturellement puisqu'à la base LFS ne propose pas de solution de gestion des packages.
J'ai d'abord utilisé "install-log" http://install-log.sourceforge.net/ C'est un simple programme qu'il suffit de lancer après installation d'un package par "install-log <nom_package>" et qui produit une liste des fichiers créés/modifiés dans un répertoire /var/log/install-logs en se référant à la date d'un fichier /var/install-log/.timestamp C'est relativement efficace à condition de corriger quelques petits bugs dans le produit (et notamment un assez énorme qui fait que le produit se base uniquement sur le "modify time", ce qui conduit à certains oublis; il faut aussi regarder le "change time" puisque le package peut installer des fichiers relativement anciens sans les modifier - patch à ta disposition si tu veux essayer le produit).
Solution similaire: ce simple script http://linuxfromscratch.org/~gerard/log-install imaginé par le créateur de LFS.
Aujourd'hui, j'utilise une autre méthode appelée "More Control and Package Management using Package Users" http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt Elle consiste à installer les programmes, non plus sous root mais sous un "Package User". Dès lors, il est très simple de repérer un fichier installé pour un package puisqu'il le user et/ou le groupe du fichier est le nom du package. J'aime d'autant mieux cette méthode qu'elle me semble aussi beaucoup plus "secure". Qu'y a-t-il en effet de moins sécurisant que de faire un "make install" sous root, permettant l'installation sans précaution de tout et n'importe quoi (et qui ouvre notamment la possibilité de laisser écraser le fichier d'un package par un autre package, ou d'installer des programmes "setuid root" qui peuvent se révéler dangereux). -- Cdlt Cem
