Premièrement, une clause de non-responsabilité en matière de conflit d’intérêts: je suis un développeur de longue date de GoboLinux.
Deuxièmement, une revendication initiale d’expertise de domaine: je suis un développeur de longue date de GoboLinux.
Quelques structures différentes sont actuellement utilisées. GoboLinux en a un, et des outils comme GNU Stow , Homebrew , etc. utilisent quelque chose de très similaire (principalement pour les programmes utilisateur). NixOS utilise également une hiérarchie non standard pour les programmes et la philosophie de la vie. C'est aussi une expérience LFS relativement commune.
Je vais décrire tout cela, puis commenter par expérience comment cela fonctionne dans la pratique ("faisabilité"). La réponse courte est que oui, c'est faisable, mais vous devez le vouloir vraiment .
GoboLinux
GoboLinux a une structure très similaire à celle que vous décrivez. Le logiciel est installé sous /Programs: /Programs/ZSH/5.0.8contient tous les fichiers appartenant à ZSH 5.0.8, dans les répertoires habituels bin/ lib/ .... Les outils système créent des liens symboliques vers ces fichiers dans une /System/Linkshiérarchie qui correspond à /usr¹. La PATHvariable ne contient que le seul répertoire exécutable unifié et LD_LIBRARY_PATHest inutilisée. Plusieurs versions de logiciel peuvent coexister à la fois, mais un seul fichier portant un nom donné ( bin/zsh) sera lié de manière active à la fois. Vous pouvez accéder aux autres par leurs chemins complets.
Un ensemble de compatibilité existe aussi des liens symboliques, donc /binet la /usr/bincarte dans le répertoire unifié executables, et ainsi de suite. Cela facilite la vie des logiciels au moment de l'exécution. Un correctif de noyau, GoboHide, permet à ces liens symboliques de compatibilité d’être masqués des listes de fichiers (tout en restant utilisables).
Par contre, vous n’avez pas besoin de modifier le code du noyau: GoboHide est purement esthétique et le noyau ne dépend pas des chemins d’espace utilisateur en général². GoboLinux a un système d'init sur mesure, mais ce n'est pas nécessaire pour le faire.
Le slogan a toujours été "le système de fichiers est le gestionnaire de paquets", mais il existe des outils de gestion de paquets assez ordinaires dans le système. Vous pouvez tout faire avec cp, rmet ln, cependant.
Si vous voulez utiliser GoboLinux, vous êtes le bienvenu. Je noterai cependant qu'il s'agit d'une petite équipe de développement et que vous constaterez probablement que certains logiciels que vous souhaitez ne sont pas fournis si personne n'a voulu les utiliser auparavant. La bonne nouvelle est qu’il est généralement assez facile de créer un programme pour le système (une "recette" standard dure environ trois lignes); la mauvaise nouvelle est que parfois c'est compliqué, ce que je vais couvrir plus en détail ci-dessous.
Des publications
Il y a quelques "publications". J'ai présenté sur linux.conf.au 2010 un exposé sur l'ensemble du système, qui est disponible en vidéo: ogv mp4 (également sur votre miroir local Linux Australia); J'ai aussi écrit mes notes en prose. Il existe également quelques documents plus anciens, dont le fameux " Je ne suis pas clueless ", sur le site Web de GoboLinux , qui aborde certaines objections et certains problèmes. Je pense que nous sommes tous un peu moins gung-ho ces jours-ci, et je suspecte qu'une prochaine version adoptera /usrl'emplacement de base des liens symboliques.
NixOS
NixOS place chaque programme installé dans son propre répertoire sous /nix/store. Ces répertoires sont nommés comme suit /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/: il existe un hachage cryptographique représentant l'ensemble des dépendances et de la configuration menant à ce programme. À l'intérieur de ce répertoire se trouvent tous les fichiers associés, avec des emplacements plus ou moins normaux localement.
Il vous permet également d’avoir plusieurs versions à la fois et de n’en utiliser aucune. NixOS est associé à une philosophie de configuration reproductible: il intègre essentiellement un système de gestion de la configuration depuis le début. Certaines manipulations environnementales sont nécessaires pour présenter le monde adéquat de programmes installés à l'utilisateur.
LFS
Il est assez simple de passer par Linux From Scratch et de configurer exactement la hiérarchie souhaitée: créez simplement les répertoires et configurez tous les éléments à installer au bon endroit. Je l'ai fait plusieurs fois lors de la construction d'expériences sur GoboLinux, et ce n'est pas beaucoup plus difficile que LFS ordinaire. Dans ce cas, vous devez créer les liens symboliques de compatibilité. sinon, c'est beaucoup plus difficile, mais une utilisation prudente des montures syndicales pourrait probablement éviter cela si vous le souhaitiez vraiment.
J'ai l'impression qu'il y avait un indice de LFS à ce sujet exactement à un moment donné, mais je n'arrive pas à le trouver maintenant.
Sur la faisabilité
La particularité de la FHS est qu’elle est une norme, qu’elle est très répandue et qu’elle reflète globalement l’usage existant au moment de sa rédaction. La plupart des utilisateurs ne seront jamais sur un système qui ne suit pas essentiellement cette disposition. Le résultat de cela est que beaucoup de logiciels ont des dépendances latentes que personne ne réalise, souvent de manière totalement involontaire.
Tous ces scripts avec #!/bin/bash? Pas bon si vous n'avez pas Bash là-bas. C'est pourquoi GoboLinux a tous ces liens symboliques de compatibilité; c'est juste pratique. Un grand nombre de logiciels ne fonctionnent pas au moment de la construction ou de l'exécution sous une présentation non standard, et il faut ensuite appliquer des correctifs pour les corriger, souvent de manière très intrusive.
Votre programme de base Autoconf s’installe généralement avec plaisir partout où vous le dites, et il est assez facile d’automatiser le processus de transmission du correct --prefix. Les autres systèmes de construction ne sont pas toujours aussi agréables, qu'ils soient intentionnels dans la hiérarchie ou bien par des auteurs de premier plan pour écrire une configuration non portable. CMake est un délinquant majeur dans cette dernière catégorie. Cela signifie que si vous voulez vivre dans ce monde, vous devez être prêt à faire beaucoup de travail fastidieux dans les systèmes de construction des autres. C'est un vrai problème d'avoir à patcher dynamiquement les fichiers générés lors de la compilation.
Le temps d'exécution est encore une autre affaire. De nombreux programmes ont des suppositions sur l'endroit où leurs propres fichiers, ou ceux de quelqu'un d'autre, sont trouvés par rapport à eux ou absolument. Lorsque vous commencez à utiliser des liens symboliques pour présenter une vue cohérente, de nombreux programmes ont des bogues qui les traitent (ou parfois, un comportement correct qui ne vous est d'aucune aide). Par exemple, un outil foobarpeut s’attendre à trouver l’ bazexécutable à côté ou dans ../sbin. Selon qu’il lit son lien symbolique ou non, il peut s’agir de deux endroits différents, et aucun d’eux ne peut être correct de toute façon.
Un problème combiné est le /usr/sharerépertoire. C'est pour les fichiers partagés, bien sûr, mais lorsque vous mettez chaque programme dans son propre préfixe, ils ne sont plus réellement partagés. Cela conduit à des programmes incapables de trouver des icônes standard, etc. GoboLinux a traité cela de manière assez moche: au moment de la construction, il $prefix/shares'agissait d'un lien symbolique vers $prefix/Shared, et après la construction du lien, il a été sharedirigé vers le répertoire global . Il utilise maintenant le sandboxing au moment de la compilation et le déplacement de fichiers pour traiter share(ainsi que les autres répertoires), mais les erreurs d'exécution liées à la lecture des liens peuvent toujours poser problème.
Les suites de plusieurs programmes sont un autre problème. GoboLinux n’a jamais complètement fait fonctionner GNOME, et je ne pense pas que NixOS l’ait été non plus, car les interdépendances de la structure sont si complexes qu’il est impossible de toutes les soigner.
Donc, oui, c'est faisable , mais:
- Pour que les choses fonctionnent, il y a beaucoup de travail à faire.
- Certains logiciels peuvent ne jamais fonctionner.
- Les gens vont vous regarder drôle.
Tout cela peut ou peut ne pas être un problème pour vous.
¹ La version 14.01 utilise /System/Index, qui mappe directement sur /usr. Je soupçonne qu'une future version pourrait abandonner la hiérarchie Liens / Index et l'utiliser /usrde manière généralisée.
² Il faut /bin/shexister par défaut.