Bonsoir
Le 19/10/2022 à 22:52, Frédéric a écrit :
> Le mercredi 19 octobre 2022, Olivier a écrit :
>
>> L'utilisation de lien symbolique sur les répertoires est une solution
>> temporaire plutôt élégante, qui évite de tout casser.
>
> 3 niveaux de liens symboliques pour une librairie aussi essentielle, je ne
> trouve pas ça franchement élégant !
/lib64/ld-linux-x86-64.so.2 (lien)
-> /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (lien)
-> /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (vrai fichier)
Ce n'est pas le boulot du paquet usrmerge, c'est un fonctionnement
"normal" de Debian. A savoir qu'en fonction des SW (si ils sont i686 ou
x86_64, ils vont pointer sur telle ou telle architecture.
Ainsi, chez moi j'ai:
- 684 paquets "all". Qui sont indépendant de l'architecture hardware
(fonts, fichier de doc, script php/perl/python/....)
- 2198 paquets "x86_64 / amd64", donc des programmes 64bits
- 237 paquets "i386", qui sont des applis 32bits. Une partie est au
moins lié à l'installation d'un "wine 32bits".
La commande "ldd" peut t'aider à comprendre quelles sont les
dépendances entre programmes est librairies.
Example:
$ which bash
/usr/bin/bash
$ ldd /usr/bin/bash
linux-vdso.so.1
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
/lib64/ld-linux-x86-64.so.2
=> Tu vois que certaines librairies, comme libtinfo.so.6, pointe vers
une version spécifique 64bit : /lib/x86_64-linux-gnu/libtinfo.so.6
=> D'autres par contre laisse le choix au système, et aussi à la
variable $LD_LIBRARY_PATH de choisir la 1ère librairie venue (exemple;
linux-vdso.so.1)
Enfin, Debian a tendance à un peu abuser des liens dans tous les sens:
$ which vi
/usr/bin/vi
/usr/bin/vi -> /etc/alternatives/vi
/etc/alternatives/vi -> /usr/bin/vim.basic
/usr/bin/vim.basic
$ which vim
/usr/bin/vim
/usr/bin/vim -> /etc/alternatives/vim
/etc/alternatives/vim -> /usr/bin/vim.basic
/usr/bin/vim.basic
Ce n'est pas simple, mais cela offre une certains flexibilité. ici, les
programmes "vi" et "vim" pointent sur le même exécutables, tout en
permettant au programme de savoir si il a été appelé sous le nom "vi" ou
"vim", ce qui peut être utile/
> Et usrmerge, il est bien gentil : "Ah, c'est le bordel, faut gérer ça vous
> même". Sauf que dans la situation où il a laissé les choses, c'est
> ingérable depuis le système lui-même...
Juste une question, la machine en question, elle ne serait pas sous
"Sid / Unstable" par hasard ? Donc dans ce cas-là, il n'est pas étonnant
que tu ais des problème, car "unstable" c'est justement la version de
Debian qui sert à détecter les problèmes.
> Au passage, ça gênait en quoi, de laisser les choses comme elles étaient ?
> Parce qu'avec l'embarqué et ses ressources limitées, ça peut quand même
> être bien utile de séparer.
CF autres commentaires.
Je dirais qu'en 2022, vu la taille des disques, il n'est probablement
plus nécessaire de procéder à une telle fragmentation. Surtout pour les
binaires / exécutables.
Cordialement,
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
