Package perso qui supprime /opt/ suite à un remove

Le
Francois Lafont
Bonjour à tous,

Je me suis fait un paqckage perso qui consistait simplement
à déposer des fichiers dans /opt/mon-paquet. Je ne suis pas
un expert en packaging mais je pense que le paquet était fait
à peu près correctement (j'ai mis un fichier mon-paquet.install
dans le répertoire de build debian/ et voilà).

Mais lorsque je faisais un remove (apt-get remove mon-paquet),
le répertoire /opt/ était tout simplement effacé plus de
/opt/ sur mon système. Ça fait un peu drôle quand même.
Est-ce vraiment normal ?

Au départ, je me suis dit que c'est parce que j'ai un paquet
qui s'installe dans /opt/ et que /opt/ n'est pas fait pour
ça. Mais quand je lis ici :

http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES

« /opt is reserved for the installation of add-on application
software packages. »

Je me dis que que finalement /opt/ est une destination licite
pour un paquet.

Autre point : avant le remove, si je mets un petit fichier dans
/opt/ (via un petit « touch /opt/toto » et qu'ensuite je fais
un remove, j'obtiens :

dpkg: warning: unable to delete old directory '/opt': Directory not empty

Ouf, ça va. Debian est gentil avec moi et n'ira pas jusqu'à
m'effacer des fichiers autres que ceux du paquet. Donc rien
de très grave au final.

J'ai trouvé ce message sur le web :
https://lists.debian.org/debian-devel/2006/03/msg00214.html

où en gros il est expliqué que tout ça est normal et que
si j'ai bien compris :

lors d'un remove d'un paquet si
1. plus aucun paquet installé sur le système ne n'a de fichier
recensé dans un répertoire A et
2. qu'il s'avère que ce répertoire A devient totalement vide
suite à la suppression du paquet
alors dpkg détruit le répertoire A. Enfin, si au moins une
des deux conditions 1 et 2 n'est pas remplies alors le
répertoires A est alors conservé (avec un petit warning
dans le cas où 1 est remplie mais pas 2).

Bref, tout ça pour dire qu'après quelques recherches, ce que je
trouve penche plutôt pour le fait que la disparition de /opt/
soit finalement « normale ». Mais en même temps, ça j'ai du mal
à me résoudre au fait que ça soit normal de ne plus avoir de /opt/
sur mon système après un remove, alors que /opt/ fait quand même
partie du "Filesystem Hierarchy Standard". Ça me semble bien
étrange.

En pratique, on peut toujours s'arranger pour recréer
le répertoire /opt/ dans le script postrm bien sûr. Et,
toujours en pratique, le problème se résout sans difficulté.
Mais ce qui m'intéresse, c'est surtout de savoir si ce
phénomène est normal ou non et si ce n'est pas normal,
qu'elle est mon erreur dans l'histoire.

Merci de vos lumières.

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/lbr0br$9fd$1@ger.gmane.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 4
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Charles Plessy
Le #25950092
Le Thu, Jan 23, 2014 at 01:02:15PM +0100, Francois Lafont a écrit :

En pratique, on peut toujours s'arranger pour recréer
le répertoire /opt/ dans le script postrm bien sûr. Et,
toujours en pratique, le problème se résout sans difficulté.
Mais ce qui m'intéresse, c'est surtout de savoir si ce
phénomène est normal ou non et si ce n'est pas normal,
qu'elle est mon erreur dans l'histoire.



Bonjour,

le comportement de dpkg est normal.

Dans un système standard Debian, c'est le paquet base-files qui contient les
répertoires vides les plus fréquents, pour qu'ils ne soient pas effacés quand
plus aucun autre paquet n'y dépose des fichiers.

Comme Debian n'utilise pas /opt, aucun paquet officiel ne s'assure de son
existence, donc l'installation puis le retrait d'un paquet local utilisant /opt
peut provoquer son effacement.

Je pense que « touch /opt/ne-m-effacez-pas » est une solution suffisante
pour un simple système local.

Amicalement,

--
Charles Plessy
Tsurumi, Kanagawa, Japon

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Bzzz
Le #25950152
On Thu, 23 Jan 2014 22:07:41 +0900
Charles Plessy
Je pense que « touch /opt/ne-m-effacez-pas » est une solution
suffisante pour un simple système local.



Oui, c'est d'ailleurs ce qui est fait pour /etc/cron.d:

cat /etc/cron.d/.placeholder
# DO NOT EDIT OR REMOVE
# This file is a simple placeholder to keep dpkg from removing this directo ry

--
BOFH excuse #66:
bit bucket overflow

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Francois Lafont
Le #25950212
Bonjour,

Le 23/01/2014 14:07, Charles Plessy a écrit :

le comportement de dpkg est normal.



Ah, ça me rassure. ;-)

Dans un système standard Debian, c'est le paquet base-files qui contient les
répertoires vides les plus fréquents, pour qu'ils ne soient pas effacés quand
plus aucun autre paquet n'y dépose des fichiers.

Comme Debian n'utilise pas /opt, aucun paquet officiel ne s'assure de son
existence, donc l'installation puis le retrait d'un paquet local utilisant /opt
peut provoquer son effacement.



Ok, parfait.

Donc finalement la règle serait donc : au moment d'un remove les fichiers du
paquet sont supprimés et si un répertoire qui contenait un de ces fichiers
devient vide suite à ce remove alors le répertoire est supprimé aussi *SSI* il
ne fait pas partie du paquet base-files (car debian n'a naturellement aucune
raison de supprimer un fichier-répertoire d'un paquet installé sur le système).

Je pense que « touch /opt/ne-m-effacez-pas » est une solution suffisante
pour un simple système local.



Je ne vois pas trop ce que tu appelles un système "local" ?

Bon, de toute façon, j'ai une nouvelle version du paquet qui va dans
/usr/share/le-paquet (sachant que /urs/share fait bien partie de
base-files... en même temps avant que ce répertoire soit vide...)
et donc je n'aurai plus le « problème ». J'ai juste ajouté un
« [ ! -e /opt ] && mkdir /opt » dans le postinst du paquet "nouvelle
version" afin que je garde quand même un /opt après upgrade (parce
que ça me chagrine un peu de ne plus voir de /opt sur le système,
même si Debian lui s'en moque ;-)).

Merci beaucoup pour tes explications Charles.

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/lbr5u6$f1s$
Stéphane GARGOLY
Le #25951192
Bonjour à tous les utilisateurs et développeurs de Debian :

Le 23/01/2014, Francois Lafont
Je me suis fait un paqckage perso qui consistait simplement
à déposer des fichiers dans /opt/mon-paquet. Je ne suis pas
un expert en packaging mais je pense que le paquet était fait
à peu près correctement (j'ai mis un fichier mon-paquet.install
dans le répertoire de build debian/ et voilà).

Mais lorsque je faisais un remove (apt-get remove mon-paquet),
le répertoire /opt/ était tout simplement effacé... plus de
/opt/ sur mon système. Ça fait un peu drôle quand même.
Est-ce vraiment normal ?



D'après Charles Pl. (dans son précédent message de ce fil de
discussion), le résultat constaté (le répertoire /opt supprimé) est
normal.

Cependant, dans tout paquet Debian, il y a une archive
"control.tar.gz" contenant, entre autres, les scripts "prerm" et
"postrm" (note a). Mes connaissances (dans le domaine de
l'empaquetage) sont limitées mais je me demande s'il n'existe pas une
solution (par l'intermédiaire de ces 2 scripts) pour éviter que les
commande 'apt-get' ou 'dpkg' ne supprime /opt lors de la suppression
de ton paquet.

Note a : si on veux savoir un peu plus sur ces scripts précités (mais
il y a aussi les "preinst" et "postinst"), voir le lien
http://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.fr.html#s-maints cripts
.

Maintenant, à mon avis, je ne pense pas que la présence (ou non) des
répertoires "vides" - tels que /opt ou /srv, c'est du moins que j'ai
constaté chez moi (note b) - ait une quelconque conséquence pour le
bon fonctionnement d'un système GNU/Linux. La seule chose est qu'un
répertoire "vide" occupe simplement un inode dans un système de
fichier de type "extn" (avec n égal à 2, 3 ou 4).

Toujours chez moi, les /opt et /srv sont toujours présents dans
l'arborescence mais j'aurais très bien pu les supprimer...

Note b : il y a aussi les /mnt et /media mais il ne faut pas les
supprimer car ils servent de points de montage pour des systèmes de
fichiers temporaires ou intermittents. ;-)

Si tu veux, malgré tout, retrouver ton répertoire /opt, il suffit
d'exécuter les commandes suivantes (sous "root") : "mkdir /opt" et, si
cela est nécessaire, "chmod 755 /opt".

Au départ, je me suis dit que c'est parce que j'ai un paquet
qui s'installe dans /opt/ et que /opt/ n'est pas fait pour
ça. Mais quand je lis ici :

http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREP ACKAGES

« /opt is reserved for the installation of add-on application
software packages. »

Je me dis que que finalement /opt/ est une destination licite
pour un paquet.



On aurait pu mettre ton paquet dans le répertoire "/usr/local".
D'ailleurs, j'ai un peu du mal de faire la distinction entre ces deux
répertoires au niveau de leur utilité (note c). L'un des deux ne
fait-il pas doublon de l'autre ? :-/

J'aurais pu dire la même chose (et poser la même question) quant aux
répertoires "/mnt" et "/media".

Note c : je me souviens, il y a plus de 12 ans et pendant 2 ou 3
versions, que ma première distribution (SuSE devenue par la suite
OpenSuSE) se servait du répertoire "/opt" pour y installer des
logiciel tels que KDE, Mozilla ou StarOffice... Personnellement, je
trouve intéressant que l'on sert de /opt pour installer des
environnements de bureau et des applications graphiques (ou de type
GUI) mais Debian a fait un autre choix. Résultat : le répertoire
"/usr" est devenu quelque peu "obèse". :-)

Bref, tout ça pour dire qu'après quelques recherches, ce que je
trouve penche plutôt pour le fait que la disparition de /opt/
soit finalement « normale ». Mais en même temps, ça j'ai du mal
à me résoudre au fait que ça soit normal de ne plus avoir de /opt/
sur mon système après un remove, alors que /opt/ fait quand même
partie du "Filesystem Hierarchy Standard". Ça me semble bien
étrange.



Il faut comprendre que le FHS ("Filesystem Hierarchy Standard") est
moins une norme obligatoire ou intangible qu'un convention établie de
manière "consensuelle" par des différents acteurs œuvrant pour le
logiciel libre ou à code ouvert.

Cependant, le FHS n'est pas totalement respecté par la plupart des
distribution GNU/Linux - j'ignore quelle est la situation concernant
les différentes variantes de BSD. D'ailleurs, je ne suis pas sûr que
Debian s'y conforme strictement...

Dans mes recherche, j'ai même trouvé une distribution qui ignore
totalement le FHS : GoboLinux. Je vous donne deux liens Internet si
vous voulez en savoir plus :
1. [GoboLinux] http://www.gobolinux.org/index.php?lang=fr_FR
2. [Wikipedia] http://fr.wikipedia.org/wiki/GoboLinux

Par ailleurs, il est possible de créer des répertoires non prévus par
le FHS. Toujours personnellement et pour mes besoins, j'ai créé deux
répertoires "/homf" et "/bkup" (note d).

Note d : /homf et /bkup sont des points de montage pour deux
partitions (se trouvant sur les deux disques durs de mon ordinateur de
bureau), le premier étant un second "/home" et /bkup dérivant du terme
"backup" et servant à accueillir les sauvegardes des répertoires /etc,
/home, /homf, /root et certains sous-répertoires de /var (effectuées
par un outil fourni par Debian).

Pour finir et si on veut en savoir plus sur le FHS, voir les liens suivants :
A. [Debian] http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html
B. [Wikipedia] http://fr.wikipedia.org/wiki/FHS

Cordialement et à bientôt,

Stéphane.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Charles Plessy
Le #25953012
Le Thu, Jan 23, 2014 at 02:37:23PM +0100, Francois Lafont a écrit :

Donc finalement la règle serait donc : au moment d'un remove les fichiers du
paquet sont supprimés et si un répertoire qui contenait un de ces fichiers
devient vide suite à ce remove alors le répertoire est supprimé aussi *SSI* il
ne fait pas partie du paquet base-files (car debian n'a naturellement aucune
raison de supprimer un fichier-répertoire d'un paquet installé sur le système).



La règle est plus générale: le répertoire est enlevé si il ne fait partie
d'aucun autre paquet.

Je ne vois pas trop ce que tu appelles un système "local" ?



Je voulais dire: un système personalisé auquel l'administrateur a accès
trivialement, par exemple, mon ordinateur de bureau.

S'il faut s'assurer de la présence de /opt dans un parc ou une ferme de
machines, il vaut mieux installer un paquet fait maison contentant /opt,
plutôt que de se connecter sur chaque machine et créer /opt/ne-m-efface-pas-svp
à la main.

Bon week-end,

--
Charles Plessy
Tsurumi, Kanagawa, Japan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Francois Lafont
Le #25953872
Bonjour,

Merci Stéphane pour cette réponse détaillée.
Je me permets de réagir sur un point.

Le 23/01/2014 22:13, Stéphane GARGOLY a écrit :

On aurait pu mettre ton paquet dans le répertoire "/usr/local".



Là, je dis non. ;-)

D'après ce que j'ai compris de quelques lectures ici ou là,
aucun paquet ne doit installer quoi que ce soit dans /usr/local/,
c'est interdit par la loi. :-) Ce répertoire est la chasse gardée
de l'administrateur du système, il peut y faire sa tambouille, il
a la garantie que le gestionnaire de paquets n'ira pas y toucher.

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/lc0m25$vh9$
Francois Lafont
Le #25953862
Bonjour,

Le 25/01/2014 01:00, Charles Plessy a écrit :

Donc finalement la règle serait donc : au moment d'un remove les fichiers du
paquet sont supprimés et si un répertoire qui contenait un de ces fichiers
devient vide suite à ce remove alors le répertoire est supprimé aussi *SSI* il
ne fait pas partie du paquet base-files (car debian n'a naturellement aucune
raison de supprimer un fichier-répertoire d'un paquet installé sur le système).



La règle est plus générale: le répertoire est enlevé si il ne fait partie
d'aucun autre paquet.



Oui, règle plus générale et donc plus simple.

Je ne vois pas trop ce que tu appelles un système "local" ?



Je voulais dire: un système personalisé auquel l'administrateur a accès
trivialement, par exemple, mon ordinateur de bureau.



Ah ok.

S'il faut s'assurer de la présence de /opt dans un parc ou une ferme de
machines, il vaut mieux installer un paquet fait maison contentant /opt,



Un paquet qui contiendrait /opt/ vide suffirait donc, si j'ai bien compris.

plutôt que de se connecter sur chaque machine et créer /opt/ne-m-efface-pas-svp
à la main.



Ok. Merci encore.

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/lc0m8u$vh9$
Stéphane GARGOLY
Le #25954672
Bonjour à tous les utilisateurs et développeurs de Debian :

Le 25/01/2014, Francois Lafont
Le 23/01/2014 22:13, Stéphane GARGOLY a écrit :
On aurait pu mettre ton paquet dans le répertoire "/usr/local".



D'après ce que j'ai compris de quelques lectures ici ou là,
aucun paquet ne doit installer quoi que ce soit dans /usr/local/,
c'est interdit par la loi. :-) Ce répertoire est la chasse gardée
de l'administrateur du système, il peut y faire sa tambouille, il
a la garantie que le gestionnaire de paquets n'ira pas y toucher.



"c'est interdit par la loi" : issue du Code Linuxienne ou du Code
Débianiste ? :-)

"il peut y faire sa tambouille" : d'une certaine façon, ton paquet
n'est-il pas de la "tambouille" ? o:-)

Cordialement et à bientôt,

Stéphane.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/CAAqHXE61KfZdRoCX+
Francois Lafont
Le #25954902
Bonsoir,

Le 25/01/2014 21:29, Stéphane GARGOLY a écrit :

D'après ce que j'ai compris de quelques lectures ici ou là,
aucun paquet ne doit installer quoi que ce soit dans /usr/local/,
c'est interdit par la loi. :-) Ce répertoire est la chasse gardée
de l'administrateur du système, il peut y faire sa tambouille, il
a la garantie que le gestionnaire de paquets n'ira pas y toucher.



"c'est interdit par la loi" : issue du Code Linuxienne ou du Code
Débianiste ? :-)



Je crois que c'est du point de vue Debian. Coup de chance (ma fainéantise
a bien failli avoir raison de mes courtes recherches), j'ai retrouvé la
source :

http://www.debian.org/doc/debian-policy/ch-opersys.html

Au début de la section 9.1.2, on peut lire :

« As mandated by the FHS, packages must not place any files
in /usr/local, either by putting them in the file system archive
to be unpacked by dpkg or by manipulating them in their
maintainer scripts. »

Bon, après, il est indiqué qu'un paquet peut quand même créer
des répertoires vides si j'ai bien tout compris.

"il peut y faire sa tambouille" : d'une certaine façon, ton paquet
n'est-il pas de la "tambouille" ? o:-)



Par modestie, je suis obligé de te répondre oui. :)

Je sais par exemple que si tu utilises les debhelpers pour builder
ton paquet et que tu indiques que tu veux placer des fichiers dans
/usr/local, par défault (ie à moins de réécrire des targets dans
le fichier debian/rules), ça plante. Je m'en rappelle bien parce
qu'au tout début, mon build plantait sans que je comprenne
pourquoi et j'y avais passé un peu de temps. Dès que j'ai changé
la destination des fichiers à installer (j'avais mis au départ
/usr/local donc), c'est passé comme un lettre à la poste.

À+

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/lc1oke$5u3$
maderios
Le #25955162
On 01/25/2014 04:43 PM, Francois Lafont wrote:
Bonjour,

Merci Stéphane pour cette réponse détaillée.
Je me permets de réagir sur un point.

Le 23/01/2014 22:13, Stéphane GARGOLY a écrit :

On aurait pu mettre ton paquet dans le répertoire "/usr/local".



Là, je dis non. ;-)

D'après ce que j'ai compris de quelques lectures ici ou là,
aucun paquet ne doit installer quoi que ce soit dans /usr/local/,


Bonjour
Hum... C'est nouveau ? Chez moi:
/usr/local/src répertoire pour les sources à compiler, sauf celles du
noyau (dans /usr/src)
Tout ce qui est compilé maison (sauf le noyau) est installé dans:
/usr/local/bin
/usr/local/share
/usr/local/lib
etc, etc,....
On peut également en mettre dans /opt
/opt/bin
etc, etc,...
Ce n'est qu'une histoire de conventions.
--
Maderios


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Publicité
Poster une réponse
Anonyme