Re: /sbin -> usr/sbin
Charles Plessy a écrit :
> Le Sat, Jul 11, 2020 at 12:10:07AM +0200, BERTRAND Joël a écrit :
>>
>> Je viens d'installer une debian/testing toute fraîche sur un portable
>> Toshiba et j'ai été surpris de trouver dans / des liens vers /usr :
>
> Bonjour Bertrand,
>
> c'est dans les notes de publication:
>
> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.fr.html#merged-usr
>
> Bonne fin de semaine,
>
> Charles
Merci à tous, ça m'avait échappé.
Je viens de parcourir les liens fournis et c'est vraiment une bêtise
monumentale d'autant que je n'ai vu aucune option, nulle part, pour
éviter ce comportement à la noix. La justification de la chose est
vraiment spécieuse et c'est vraiment ce genre de truc qui fait que
j'abandonne de plus en plus les linuxeries. Et le fait que Debian est la
dernière à franchir le pas n'est vraiment pas un argument valable.
Je cite :
"Amélioration de la compatibilité avec les autres Unix / Linux dans le
comportement. Après la fusion avec /usr, tous les binaires deviennent
disponibles respectivement dans : _
_ “/bin <–> /usr/bin”
_"/sbin <–> /usr/sbin _
"/lib <–> /usr/lib"
_simplement parce que /bin devient un lien symbolique vers /usr/bin,
resp /sbin vers /usr/sbin… _
Cela signifie que les scripts/programmes écrits pour d’autres Unix ou
d’autres Linux et portés à la distribution courante n’auront plus besoin
de correction pour les chemins de système de fichiers des binaires
appelés, ce qui est par ailleurs une source majeure de frustration.
/usr/bin et /bin (resp. /Usr/sbin et /sbin, …) deviennent tout à fait
équivalents."
J'ai rarement lu un truc aussi bête. /bin et /sbin contiennent les
binaires nécessaires du démarrage du système, /usr/bin et /usr/sbin les
autres. C'est simple, carré. Par ailleurs, les scripts doivent utiliser
une variable PATH, donc ce problème n'existe pas.
"Amélioration de la compatibilité avec les systèmes de compilation GNU:
la majeure partie du logiciel Linux est construite avec GNU autoconf /
automake (c’est-à-dire GNU autotools), qui ignorent la division /usr
spécifique à Linux. Le maintien de la division /usr nécessite une
gestion non triviale du projet dans le système de génération en amont et
dans les packages de votre distribution. Avec la fusion /usr, ce travail
devient inutile et le portage des paquets vers Linux devient plus simple."
Euh... J'utilise les autotools depuis 25 ans, je n'ai jamais constaté
cela (sauf si les scripts sont écrits par des pieds, mais dans ce cas,
pourquoi mettre un cataplasme sur une jambe de bois ? On corrige en
amont, on ne fait pas n'importe quoi en aval !). Les autotools sont
_justement_ faits pour gérer ce genre de problème. Quant à parler de la
compatibilité Solaris, il y a un truc que les gens oublient, c'est que
Solaris est livré comme un tout et que, à l'instar des BSD, /usr
concerne le seul système. La dernière fois que j'ai eu un Solaris entre
les pattes (un 10, j'avoue), les programmes autres que ceux du système
étaient dans /opt ou /usr/local. Chez Debian, ce n'est pas le cas, ils
sont dans /usr/bin.
Un système Unix, quel qu'il soit, doit démarrer avec un système racine
qui contient :
- /etc
- /bin
- /sbin
- /lib
et c'est tout. Je sais bien qu'on peut bricoler avec initramfs, mais ça
reste du bricolage pour contourner un problème qui ne devrait pas
exister. initramfs est déjà un truc qui ne devrait pas exister dans un
système de démarrage bien conçu (et qui est source d'un certain nombre
de problèmes amusants).
/usr qui contient les programmes utilisateurs doit être monté plus
tard, comme /usr/local s'il est sur une partition à part, /opt, /var et
/home.
Comme chez Debian, on se prend les programmes installés dans /usr (donc
dans /usr/bin et /usr/sbin), on se trimballe une partition /usr qui peut
assez rapidement être énorme. Cette décision pourrait à la limite être
compréhensible si les paquets non nécessaires au système étaient dans
/usr/local ou /opt, mais pas en vrac dans /usr.
Sur mes serveurs critiques (enfin, ceux qu'il me reste à fonctionner
sous Linux), j'ai un / qui occupe 2Go (sur du raid1), alors que /usr en
fait une quarantaine. Certaines partitions sont même en read-only pour
éviter les problèmes. Vous allez me dire que c'est encore possible en
jouant de l'initramfs. Certes, mais si /usr est montée en rw et dégage
sur une corruption du fs, c'est tout le système qui est mort, alors que
si / est en ro, on redémarre.
Il faut vraiment que je trouve le temps de rajouter dans NetBSD les
quelques trucs qui me manquent pour remplacer mes derniers serveurs
Linux par des BSD. Entre dbus qui fait des siennes, systemd qui est
d'une fiabilité douteuse dès qu'on n'est plus sur un desktop, usrmerge
et d'autres "fonctionnalités" douteuses comme le renommage des
interfaces réseau qui un coup fonctionne, un coup ne fonctionne plus
(dépendant de la version de systemd sinon ce n'est pas drôle), j'en
arrive à croiser les doigts lorsque je dois redémarrer un système à
distance. Le dernier (sur coupure de courant un peu trop longue pour
l'onduleur, mais avec un arrêt propre par apcupsd) a pris deux heures !
Je ne sais pas ce que ce fichu systemd a bien pu faire durant ce temps,
naturellement, rien d'exploitable dans les logs.
Bon, je fais encore le râleur de service, j'en ai conscience. Je ne
suis pas contre les nouveautés lorsqu'elles ont un sens, mais lorsque
c'est pour corriger des problèmes qui ne devraient pas exister, j'avoue
ne pas être franchement emballé. Au lieu de faire cela, les devs de
Debian seraient inspirés d'avoir un répertoire /rescue avec le contenu
de /bin, /sbin et le gestionnaire de paquets compilé en statique.
J'attends avec une certaine impatience la conceté suivante, la fusion
de /usr/bin avec /usr/sbin. Parce que les arguments que je lis pour la
fusion de /bin avec /usr/bin et /sbin avec /usr/sbin s'appliquent de la
même manière.
Bien cordialement,
JKB
Reply to: