Re: Debian sid et usrmerge

Startseite

Nachricht beantworten
Autor: Olivier Allard-Jacquin
Datum:  
To: guilde
Betreff: Re: Debian sid et usrmerge
    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 !!