Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Debian Package perso qui supprime /opt/ suite à un remove

Package perso qui supprime /opt/ suite à un remove

33 réponses
Avatar
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
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4
Avatar
Francois Lafont
Le 26/01/2014 18:17, Bzzz a écrit :

"Toutefois, le package peut créer des répertoires vides


^^^^^
ok, ces répertoires sont vides (répertoires pas encore
super bien identifiés à ce stade, on sait juste qu'ils
sont « sous /usr/local » ce que je trouve assez ambigu).



C'est parce que la formulation est faire en 2 fois:
1- des dirs vides dans /usr/local
2- "Ce ne sont pas des répertoires dans /usr/local,
mais sont des enfants de répertoires dans /usr/local."
Donc: /usr/local/*/<enfant de *>



Mouais, suis pas convaincu.
L'exemple donné par Sylvain avec TeXLive m'incite vraiment
à penser qu'il s'agit des répertoires vides au final.
Je parle de ce lien bien sûr :
http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2

Par ailleurs, ils peuvent être pleins, puisque:
"Ces répertoires (/usr/local/*/dir/) devraient être supprimés
sur la suppression de paquets s'ils sont vides"



Oui mais rempli par l'administrateur du système. Toujours
en reprenant l'exemple de Sylvain avec TeXLive qui va
créer le répertoire vide /usr/local/share/texmf/ afin
que l'admin du système puisse y mettre ses classes etc.
Mais le paquet TeXLive lui n'y déposera rien. Et bien
sûr, lors d'un remove/purge, si le répertoire est non
vide (parce que l'admin y a mis des classes), celui-ci
n'est pas supprimé afin que l'admin ne perde pas son
travail.

--
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/lc3pdm$t1c$
Avatar
Francois Lafont
Bonsoir,

Le 26/01/2014 10:45, maderios 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,....



Et pour construire tes paquets « maisons », tu utilises les
debhelpers ? Si oui, tu redéfinis la cible dh_usrlocal dans
ton fichier ./debian/rules ?

On peut également en mettre dans /opt
/opt/bin
etc, etc,...
Ce n'est qu'une histoire de conventions.



Oui, bien sûr, conventions que chacun est libre de respecter
ou non, pas de problème. Après justement je m'interrogeais
sur la convention telle que définie par la Debian policy.
Au départ, je pensais qu'un paquet respectueux d'elle ne
devait strictement rien dans /usr/local ce qui était faux.


--
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/lc3pmf$vcc$
Avatar
Sylvain L. Sauvage
Le dimanche 26 janvier 2014 19:50:22 Francois Lafont a écrit :
[…]
>> [… blabla répertoires vides blabla …]

Oui désolé si ce n'est pas passionnant, je reconnais.
Mais j'espère qu'il n'y a pas de mépris quand même der rière
ce commentaire.



Non, c’est juste une manière de résumer… un peu brutale
parfois :o)

[…]
Mais mon point de réflexion de départ, ce n'est pas
vraiment la distinction "paquet destiné à la distrib" vs
paquet « local », mais plutôt de savoir ce qui est
respectueux de la debian policy et ce qui ne l'est pas.



Justement si : la Debian Policy s’occupe des paquets destinà ©s
à la distribution. Les règles sont donc édictées en conséquence.
Quand tu fais un paquet local, tu peux contourner quelques
règles. Si tu cherches à suivre toutes les règles, tu te
retrouves à viser à faire un paquet intégrable tel quel (même si
le but n’est pas de l’intégrer) et donc tu te retr ouves plus
restreint.

[…]
> qu’un tarball).
Ok. Il me semble simplement que :

- selon la politique Debian, un paquet



_de la distribution_

peut créer des
répertoires vides /usr/local/*/machin à condition que
/usr/local/truc/ existe déjà ou fasse partie de la FHS.

- et si le répertoire n'est pas vide ce n'est plus respectueux
de la Debian policy



pour un paquet _de la distribution_.

.

Je me trompe ?



Oui, dans le sens où tu cherches à appliquer toutes les rà ¨gles
de la distribution pour un paquet qui n’a pas pour but d’ être
intégré à la distribution. Tu ne peux pas faire abstract ion de
la raison « pour être _distribuable_ » pour expliquer ou
comprendre les règles d’une _distribution_ sous préte xte que tu
ne veux pas distribuer.

Analogie automobilesque : tu construis un kart pour jouer dans
ton jardin en voulant suivre les règles des Mines pour un
véhicule routier et tu veux décortiquer la règle qui rà ©git la
garde au sol minimale.

[… debhelper se plaint …]



Parce que debhelper sert à faire simplement un paquet destiné
à s’intégrer à la distribution.

Tu veux faire un paquet Debian pour installer des trucs dans
/usr/local (ou ailleurs) parce qu’un paquet est plus pratique
qu’un simple tarball (gestion des dépendances, versionnage ,
reproductibilité, etc.).
Il me semble évident qu’un paquet local a plus de marges de
manœuvre qu’un paquet distribué, non ? Sinon, pourqu oi y a-t-il
des contournements possibles (et faciles) ?

--
Sylvain Sauvage

--
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/
Avatar
Bzzz
On Sun, 26 Jan 2014 20:58:59 +0100
Francois Lafont wrote:

Mouais, suis pas convaincu.



Dans ce cas, ne pose pas la question.

L'exemple donné par Sylvain avec TeXLive m'incite vraiment
à penser qu'il s'agit des répertoires vides au final.
Je parle de ce lien bien sûr :
http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2



Alors, pourquoi l'installer a-t-il pris la peine de créer
les mêmes DIRs que dans /usr (bin, sbin, lib, share, etc),
pour faire joli?

/usr/local est justement laissé à l'appréciation de l'admin, et
j'en connais un tas qui y mettent leurs propres pkgs &| tarballs.
Par contre, je n'en connais aucun qui installe quoi que ce soit
(volontairement) dans /opt.

Sous sid, pour pouvoir utiliser une compilation d'une version
plus récente que celle d'un pkg, sans désinstaller ce pkg,
mon $PATH fait passer /usr/local/* avant le path standard.

--
<MrPicsou> Bonjour bonjour
<MrPicsou> j'ai une petite question technique, quelqu'un pourrait m'éc lairer?
* %edcba allume la lumière
* @einstein14 changed nick to Geotrouvetou
<%edcba> enfin il aurait pu demander à riri, fifi & loulou avant
*** MrPicsou quit (quit: bande de con..)

--
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/
Avatar
Sylvain L. Sauvage
Le dimanche 26 janvier 2014 21:17:27 Bzzz a écrit :
[…]
Par contre, je n'en connais aucun qui installe quoi
que ce soit (volontairement) dans /opt.



/usr/local : les applications qui ont des répertoires bin,
lib, share… (et qui savent s’en servir) ;
/opt : les applications « gros tas de nouilles » qui n†™ont pas
de bin séparé.

Sous sid, pour pouvoir utiliser une compilation d'une version
plus récente que celle d'un pkg, sans désinstaller ce pkg,
mon $PATH fait passer /usr/local/* avant le path standard.



Euh, c’est déjà le cas par défaut.

--
Sylvain Sauvage

--
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/
Avatar
Bzzz
On Sun, 26 Jan 2014 21:31:35 +0100
"Sylvain L. Sauvage" wrote:

> Sous sid, pour pouvoir utiliser une compilation d'une version
> plus récente que celle d'un pkg, sans désinstaller ce pkg,
> mon $PATH fait passer /usr/local/* avant le path standard.

Euh, c’est déjà le cas par défaut.



Ben sèpu, il me semble que fut un temps où /usr/local était
en fin de path (mais suipusisûr).

--
<dj_nor> et dabord pourquoi on dirai UNE voiture, UNE automobile,hein ?
<dj_nor> jve pas paraitre matcho mai c pluto un truc de mec pour moi !
<Need_L> et la jante féminine, t'en fait quoi alors?

--
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/
Avatar
Francois Lafont
Le 26/01/2014 21:06, Sylvain L. Sauvage a écrit :
Le dimanche 26 janvier 2014 19:50:22 Francois Lafont a écrit :
[…]
[… blabla répertoires vides blabla …]





Oui désolé si ce n'est pas passionnant, je reconnais.
Mais j'espère qu'il n'y a pas de mépris quand même derrière
ce commentaire.



Non, c’est juste une manière de résumer… un peu brutale
parfois :o)



Ah ok, pas de souci. C'était un résumé très synthétique. :)


[…]
Mais mon point de réflexion de départ, ce n'est pas
vraiment la distinction "paquet destiné à la distrib" vs
paquet « local », mais plutôt de savoir ce qui est
respectueux de la debian policy et ce qui ne l'est pas.



Justement si : la Debian Policy s’occupe des paquets destinés
à la distribution. Les règles sont donc édictées en conséquence.
Quand tu fais un paquet local, tu peux contourner quelques
règles. Si tu cherches à suivre toutes les règles, tu te
retrouves à viser à faire un paquet intégrable tel quel (même si
le but n’est pas de l’intégrer) et donc tu te retrouves plus
restreint.



Ah ok. Alors c'est donc là où je n'étais pas au clair : donc
"paquet respectueux de la Debian policy" <=> "paquet potentiellement
destiné à la distrib". Et pour un paquet perso (local), on n'est
donc pas obligé de respecter à la lettre la Debian policy (même si
j'imagine que c'est toujours mieux d'essayer de se calquer au
mieux sur la politique qui fait autorité sur la distrib).

[…]
qu’un tarball).


Ok. Il me semble simplement que :

- selon la politique Debian, un paquet



_de la distribution_

peut créer des
répertoires vides /usr/local/*/machin à condition que
/usr/local/truc/ existe déjà ou fasse partie de la FHS.

- et si le répertoire n'est pas vide ce n'est plus respectueux
de la Debian policy



pour un paquet _de la distribution_.

.

Je me trompe ?



Oui, dans le sens où tu cherches à appliquer toutes les règles
de la distribution pour un paquet qui n’a pas pour but d’être
intégré à la distribution.



Ok. Je vois.

Tu ne peux pas faire abstraction de
la raison « pour être _distribuable_ » pour expliquer ou
comprendre les règles d’une _distribution_ sous prétexte que tu
ne veux pas distribuer.

Analogie automobilesque : tu construis un kart pour jouer dans
ton jardin en voulant suivre les règles des Mines pour un
véhicule routier et tu veux décortiquer la règle qui régit la
garde au sol minimale.



:-))
Ok, cette analogie, très parlante, m'a bien fait rire.


[… debhelper se plaint …]



Parce que debhelper sert à faire simplement un paquet destiné
à s’intégrer à la distribution.



Ok. Perso, si je me suis orienté vers les debhelper, c'est
parce qu'au départ, partant de zéro, je me suis tourné vers
de la doc en ligne et en général je préférais voir du côté
de sites Debian « officiels ». Et là je tombais presque
toujours sur debhelper il me semble. Enfin, il s'avère
que c'est pratique car debhelper fait plein de choses à
ma place (et sûrement mieux que je ne le ferais moi) comme par
exemple ajouter automatiquement des trucs dans les maintainer
scripts (entre autres choses).

Tu veux faire un paquet Debian pour installer des trucs dans
/usr/local (ou ailleurs) parce qu’un paquet est plus pratique
qu’un simple tarball (gestion des dépendances, versionnage,
reproductibilité, etc.).
Il me semble évident qu’un paquet local a plus de marges de
manœuvre qu’un paquet distribué, non ? Sinon, pourquoi y a-t-il
des contournements possibles (et faciles) ?



Oui en effet.
Merci pour les explications.


--
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/lc3t6l$4lv$
Avatar
Bzzz
On Sun, 26 Jan 2014 22:30:28 +0100
Francois Lafont wrote:

Ensuite, on peut faire des paquets qui ne respectent pas
toutes la Debian policy, ce n'est pas une obligation absolu
contrairement à ce que je pensais au départ.



Toute règle est destinée, tôt ou tard, à être bris ée
(dans les limites du raisonnable).

Et, comme te l'a fait remarquer Sylvain, les règles en
question se posent pour un pkg de la distrib…

--
Si l'homme a été crée avant la femme, c'était pour lui permettre de
placer quelques mots. -- Jules Renard

--
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/
Avatar
Francois Lafont
Le 26/01/2014 21:17, Bzzz a écrit :
On Sun, 26 Jan 2014 20:58:59 +0100
Francois Lafont wrote:

Mouais, suis pas convaincu.



Dans ce cas, ne pose pas la question.



Désolé Bzzz, mais malheureusement l'apprentissage n'est
pas quelque chose d'algorithmique et de déterministe.
Après quelques aléas, je pense finalement que, contrairement
à ce que tu as écris (et qui m'a fait douter je le concède),
dans ce lien :

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

lien issu de la sacro-sainte Debian policy, il s'agit bel
et bien de répertoires *vides* (« empty ») *uniquement*.
L'exemple de TeXlive avec /usr/local/share/texmf/ me permet
de mieux comprendre le sens de ce paragraphe. Ce sont des
répertoires vides pour dire à l'admin « tu peux mettre tes
fichiers machins-trucs là-dedans si tu veux, ils seront
a priori utilisés par telle ou telle appli (latex par ex)
et le système de package ne te les effacera pas, c'est
garanti. »

Ensuite, on peut faire des paquets qui ne respectent pas
toutes la Debian policy, ce n'est pas une obligation absolu
contrairement à ce que je pensais au départ.

--
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/lc3up7$l2b$
Avatar
Francois Lafont
Le 26/01/2014 22:37, Bzzz a écrit :

Ensuite, on peut faire des paquets qui ne respectent pas
toutes la Debian policy, ce n'est pas une obligation absolu
contrairement à ce que je pensais au départ.



Toute règle est destinée, tôt ou tard, à être brisée
(dans les limites du raisonnable).



Oui, c'est vrai, je suis d'accord.

Et, comme te l'a fait remarquer Sylvain, les règles en
question se posent pour un pkg de la distrib…



Absolument, je reconnais sans problème que j'avais tort
sur ce point là, comme je l'ai déjà indiqué auparavant.
Et tout mes excuses pour ça. Je n'ai aucun problème à
reconnaître mes erreurs, vraiment.

De ton côté, est-ce que tu voudras bien admettre alors que
dans ce lien :

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

il s'agissait bel et bien de répertoires vides et que mon anglais
n'est finalement pas si catastrophique que ça ? ;-)

--
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/lc3vu3$kr$
1 2 3 4