L'une des dernières propositions de changement déposées pour Fedora 40 est d'unifier les emplacements /usr/bin et /usr/sbin. La proposition de modification explique : « Le répertoire /usr/sbin devient un lien symbolique vers bin, ce qui signifie que des chemins comme /usr/bin/foo et /usr/sbin/foo pointent vers le même endroit. /bin et /sbin sont déjà des liens symboliques vers /usr/bin et /usr/sbin, de sorte que /bin/foo et /sbin/foo pointent également vers le même endroit. /usr/sbin sera supprimé du $PATH par défaut ».
Dans Fedora 41, les emplacements sont désormais unifiés. La séparation entre /bin et /sbin n'est plus utile, les besoins antérieurs n'étant plus pertinents. Fedora a fusionné il y a plusieurs années /bin et /usr/bin et souhaite en dernier lieu unifier /usr/bin et /usr/sbin.
Le répertoire /usr/sbin deviendra un lien symbolique vers /usr/bin, ce qui signifie que les chemins tels que /usr/bin/foo et /usr/sbin/foo pointeront vers le même emplacement. Les répertoires /bin et /sbin sont déjà des liens symboliques vers /usr/bin et /usr/sbin, ce qui signifie que /bin/foo et /sbin/foo pointent également vers le même endroit.
Le répertoire /usr/sbin sera supprimé du $PATH par défaut. La même modification sera également apportée pour que /usr/local/sbin pointe vers /usr/local/bin, ce qui fait que /usr/local/bin/foo et /usr/local/sbin/foo pointent vers le même endroit. La définition de %_sbindir sera modifiée en %_bindir, de sorte que les paquets commenceront à utiliser le nouveau répertoire après une reconstruction sans autre action requise. Les mainteneurs peuvent cesser d’utiliser %_sbindir, mais ce n’est pas nécessaire
Pourquoi s'être orienté de la sorte ?
Selon Fedora, la séparation entre /bin et /sbin n’est pas utile et est également inutilisée. À l’origine, cette séparation visait à avoir des binaires “importants” liés statiquement dans /sbin, qui pouvaient ensuite être utilisés pour des opérations d’urgence et de sauvetage. Cependant, Fedora n’utilise plus la liaison statique. Plus tard, cette séparation a été repensée pour isoler les binaires “importants” qui ne seraient utilisés que par l’administrateur.
Bien que cela semble attrayant en théorie, en pratique, il est très difficile de catégoriser les programmes de cette manière, et les utilisateurs normaux invoquent régulièrement des programmes depuis /sbin. La plupart des programmes qui nécessitent des privilèges root pour certaines opérations sont également utilisés lorsqu’ils fonctionnent sans privilèges.
Et même lorsque des privilèges sont requis, ils sont souvent acquis dynamiquement, par exemple en utilisant polkit. Depuis de nombreuses années, le $PATH par défaut défini pour les utilisateurs inclut déjà les deux répertoires. Avec l’avènement de systemd, cela est devenu plus systématique : systemd définit $PATH avec les deux répertoires pour tous les utilisateurs et services. En général, tous les utilisateurs et programmes trouveraient donc les deux ensembles de binaires. Une utilisation supplémentaire de la séparation /bin — /sbin est consolehelper.
Dans cette approche, le programme orienté utilisateur (/bin/foo) est un lien symbolique vers /bin/consolehelper, qui est un binaire suid qui élève les privilèges et appelle le “vrai” foo (/sbin/foo ou /usr/libexec/foo). La plupart des utilisations de consolehelper ont été déplacées vers polkit, mais il y a encore certains utilisateurs.
L'utilisation de /sbin pour le programme privilégié est incompatible avec la fusion proposée ; ces paquets devront être ajustés pour déplacer le binaire qui nécessite des privilèges sous /usr/lib ou /usr/libexec.
Étant donné que toutes les sessions utilisateur et tous les services ont généralement les deux répertoires dans $PATH, cette séparation ne sert en fait à rien. Son principal effet est la confusion lorsque les gens ont besoin d'utiliser le chemin absolu et qu'ils se trompent de répertoire. D'autres distributions placent certains binaires dans l'autre répertoire, de sorte que le chemin absolu n'est souvent pas portable. De plus, il est très facile pour un utilisateur de se retrouver avec /sbin avant /bin dans $PATH, et pour un administrateur de se retrouver avec /bin avant /sbin dans $PATH, ce qui est source de confusion. Si cette fonctionnalité est abandonnée, le système devient un peu plus simple, ce qui est utile surtout pour les nouveaux utilisateurs, qui ne sont pas au courant de l'histoire de la séparation.
Avantages pour Fedora
- Les empaqueteurs n'ont pas à se demander s'il faut installer les programmes dans %_bindir ou %_sbindir.
- Les utilisateurs n'ont pas à se demander si les programmes se trouvent dans %_bindir ou %_sbindir.
- Fedora devient plus compatible avec les autres distributions (par exemple, nous avons /sbin/ip alors que Debian a /bin/ip, et nous avons /bin/chmem et /bin/isosize, alors que Debian a /sbin/chmem et /sbin/isosize, et nous avons aussi /sbin/{addpart,delpart,lnstat,nstat,partx,ping,rdma,resizepart,ss,udevadm,update-alternatives}, alors que Debian les a sous /bin, etc. )
- Fedora devient plus compatible avec Arch, qui a fait la fusion il y a quelques années.
- execvp et les fonctions apparentées itèrent sur moins de répertoires. Cela n'a probablement pas d'importance pour la vitesse, mais c'est une simplification agréable lorsque l'on regarde les journaux ou la sortie de strace.
Conclusion
La fusion des répertoires /bin et /sbin simplifiera la gestion des paquets et rendra Fedora plus compatible avec d’autres distributions Linux. Cette modification suit l’exemple d’Arch Linux, qui a fusionné sbin et bin en 2013. Elle permettra également d’éliminer la référence au répertoire /usr/sbin du $PATH une fois que tous les fichiers exécutables seront consolidés en un seul endroit
Source : Fedora
Et vous ?
Pensez-vous que la fusion de /bin et /sbin est une bonne décision ? Pourquoi ou pourquoi pas ? Quels sont les avantages et les inconvénients de cette fusion ? Avez-vous déjà rencontré des problèmes avec la séparation actuelle entre /bin et /sbin ? Comment pensez-vous que cela affectera les utilisateurs et les administrateurs système ? Quelles autres distributions Linux ont déjà fusionné ces répertoires, et quelles leçons pouvons-nous en tirer ? 
.