xz-utils have inconsistent binary Le sujet est résolu

[dtrckd]

I have two identical binary copy at
- /bin/xz
- /usr/bin/xz

(They are not symlink)

But when a look a `apt-file list xz-utils` it says that only /usr/bin/xz should exist.

Does someone knows why we have two binaries file instead of one ? Don't it feels like un unlikely duplicate ?

Kernel: 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13)

[MicP]

Bonjour
Hi

/bin est un fichier de type lien
qui est lié au répertoire /usr/bin

/bin is a link file
which is linked to the /usr/bin directory

Code : Tout sélectionner

mic@deb116:~$ ls -l /bin
lrwxrwxrwx 1 root root 7  5 janv. 13:02 /bin -> usr/bin
mic@deb116:~$ 

Donc, les chemins absolus /bin/xz et /usr/bin/xz
permettent d'accéder au même seul et unique fichier xz

So the absolute paths /bin/xz and /usr/bin/xz
allow access to the same single file xz.

Code : Tout sélectionner

mic@deb116:~$ ls -li  /{,usr/}bin/xz
1335061 -rwxr-xr-x 1 root root 81192 11 avril  2022 /bin/xz
1335061 -rwxr-xr-x 1 root root 81192 11 avril  2022 /usr/bin/xz
mic@deb116:~$ 

[dezix]

Bonjour,

I have to point out that we are a French speaking forum,
so please use our regular language,
thanks.


Pour répondre à la question :

J'ai la même chose sur mon système stable :

Code : Tout sélectionner

$ ls -l  /{,usr/}bin/xz
-rwxr-xr-x 1 root root 81192 11 avril  2022 /bin/xz
-rwxr-xr-x 1 root root 81192 11 avril  2022 /usr/bin/xz

Donc cela doit-être normal sans que je ne sois en mesure d'apporter d'explication documentée.

[dtrckd]

Hello,

ah pardon, j'ai écrit machinalement en anglais (je suis Francais ^^).

Je ne m'étais jamais rendu compte que `/bin` pointé vers `/usr/bin`, j'en tombe des nues !

Tout de même cela me laisse perplexe car, par rapport au problème qui m'a amené à poser la question à savoir : "De quel package provient xz ?"

Pour y répondre, on peut typiquement faire : `dpkg -S $(which xz)`

Le problème est que la commande échouera car "which xz" renvoie /bin/xz, et dpkg donne une réponse seulement pour l'entrée '/usr/bin/xz' pour cette exemple.

Est-ce que cela est un problème connue ? Vaut' il le coup d'être remonté ? (j'imagine qu'il a des choses plus importantes à traiter dans Debian...?)

[PascalHambourg]

Le problème est que la commande échouera car "which xz" renvoie /bin/xz, et dpkg donne une réponse seulement pour l'entrée '/usr/bin/xz' pour cette exemple.

C'est pourquoi il faut ajouter l'option -a afin que which recherche dans tous les chemins et ne s'arrête pas au premier trouvé.

Est ce que cela est un problème connu ?

Oui, archi-connu, débattu... Ça fait partie des problèmes soulevés par la fusion de /bin, /lib* et /sbin par liens symboliques dans /usr ("/usr-merge", c'est ainsi que ça s'appelle si le sujet t'intéresse) mise en place à l'installation depuis buster, et qui rendent le mainteneur de dpkg grognon.

[dezix]

"which xz" renvoie /bin/xz

Tient, c'est marrant, pas chez-moi :

Code : Tout sélectionner

$ which xz
/usr/bin/xz

$ which -a xz
/usr/bin/xz
/bin/xz

$ dpkg -S `which xz`
xz-utils: /usr/bin/xz

$ dpkg -S `which -a xz`
xz-utils: /usr/bin/xz
dpkg-query: aucun chemin ne correspond à /bin/xz

[PascalHambourg]

C'est vrai que d'habitude, /usr/bin est placé avant /bin dans $PATH, donc which trouvera la commande dans /usr/bin en premier. Cela ne devrait donc poser problème à dpkg que pour les commandes installées dans /bin comme mount.

[dtrckd]

Merci pour vos réponses, j' y vois plus clair désormais.

En effet, mon $PATH est défini par mes soins, et /bin était placés avant /usr/bin ce qui explique la différence de nos résultats vis à vis de which.

Bonne journée,
ad

[dtrckd]

Ici se trouve un article qui expose le sujet, pour référence : https://lwn.net/Articles/890219/

[dezix]

Ici se trouve un article qui expose le sujet, pour référence : https://lwn.net/Articles/890219/

Je n'ai pas eu la force de tout lire,
mais il me semble assez décevant que, au sein d'un projet comme Debian,
les parties-prenantes aient autant de difficultés à parvenir à un consensus sur des choix techniques.

Je comprends bien que toute chose puisse avoir des avantages et des inconvénients,
et même qu'il ne soit pas simple de déterminer de quel côté penche la balance.

Mais en arriver de telles dissensions sans parvenir à une ligne clairement définie,
je trouve cela bien dommage.

Surtout lorsque je lis :

• Does dpkg support merged-/usr-via-aliased-dirs?
• dpkg-fsys-usrunmess(8)

Q: Does dpkg support merged-/usr-via-aliased-dirs?
(Est-ce que dpkg supporte "merged-/usr-via-aliased-dirs" ?)

A: No. This approach is considered broken by design and breaks many common expectations...
(Non. Cette approche est considérée comme cassée par la nature et brise de nombreuses attentes courantes...)

et que, j'ai bel et bien :

Code : Tout sélectionner

$ ls -dl /bin                                                 
lrwxrwxrwx 1 root root 7 31 mars   2021 /bin -> usr/bin

À ce stade, je pense qu'on est en droit de se poser des questions...
car le système est installé par l'installateur d'une manière
que l'équipe maintenant DPKG considère comme cassée...


Sincèrement je ne sais pas quoi en penser.

[PascalHambourg]

La fusion d'/usr par alias de répertoires facilite la vie des développeurs de logiciels, des mainteneurs de paquets des distributions et des utilisateurs. Les uns n'ont plus à se demander si tel exécutable ou bibliothèque doit être installé dans /usr ou dans la racine, les autres n'ont plus à se demander s'il est dans /usr ou dans la racine. Où qu'il soit installé, il est disponible aux deux endroits. Mais cela peut aussi poser des problèmes pour les gestionnaires de paquets, dpkg en ce qui concerne Debian.

La page "FAQ dpkg" du wiki Debian reflète le point de vue du mainteneur de dpkg, pas du projet Debian dans son ensemble. La fusion d'/usr est en vigueur dans toute nouvelle installation depuis buster. Il est vrai qu'elle n'est pas compatible avec l'implémentation actuelle de certaines fonctionnalités de dpkg, mais cela ne justifie pas d'affirmer que la fusion d'/usr par alias de répertoires est "cassée par nature".

[dezix]

Merci pour cette mise au point.