Quelles sont les alternatives à la FHS?

Je suis un utilisateur Linux de longue date depuis plus de 15 ans, mais je déteste passionnément la structure de répertoires obligatoire. Je ne aime pas ça /usr/binest le sol de dumping pour les fichiers binaires ou libs dans /usr/lib, /usr/lib32, /usr/libx32, /lib, /lib32etc ... Au hasard des choses dans /usr/shareetc. Il est muet et confus. Mais certains aiment et les goûts diffèrent.

Je veux une structure de répertoire où chaque paquet est isolé. Imaginez plutôt si le lecteur multimédia Media Player avait sa propre structure:

/software/dragon
/software/dragon/bin/x86/dragon
/software/dragon/doc/README
/software/dragon/doc/copyright
/software/dragon/lib/x86/libdragon.so

Ou:

/software/zlib/include/zlib.h
/software/zlib/lib/1.2.8/x86/libz.so
/software/zlib/lib/1.2.8/x64/libz.so
/software/zlib/doc/examples/...
/software/zlib/man/...

Tu obtiens le point. Quelles sont mes options? Existe-t-il une distribution Linux qui utilise quelque chose comme mon schéma? Certaines distributions peuvent-elles être modifiées pour fonctionner comme je le veux (Gentoo?) Ou ai-je besoin de LFS? Existe-t-il des antériorités dans ce domaine? Comme des publications sur si le programme est réalisable ou non?

Je ne cherche pas OS X. :) Mais inspiré par OS X est totalement correct.

Edit : Je ne sais pas comment PATH, LD_LIBRARY_PATHet d’autres variables d’environnement qui dépendent d’un petit ensemble de chemins devraient fonctionner. Je pense que si Kate, l' éditeur de KDE, est installé, /software/kate/bin/x86/bin/kateje peux alors taper le chemin d'accès complet au binaire pour le démarrer. Comment cela devrait-il fonctionner pour les bibliothèques dynamiques et les dlopenappels, je l'ignore, mais il ne peut s'agir d'un problème d'ingénierie insoluble.

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.

Les guichets GoboLinux (dont F.sb a parlé) et GNU sont des distributions qui utilisent une structure de répertoires par paquet ainsi que des liens symboliques pour pointer vers la version "actuelle" d'un binaire.

GoboLinux semble être le meilleur choix si vous voulez un système stable. GNU Guix dit explicitement qu'il n'est pas encore prêt pour la production. GoboLinux existe depuis des années. Je n'ai jamais essayé non plus moi-même.

vérifiez le GoboLinux .

si vous souhaitez que la structure de répertoires soit modifiée, vous devez modifier le code du noyau, le processus de démarrage, les niveaux d'exécution de répertoires basés sur les fichiers rc et le gestionnaire de packages, puis la structure de répertoires.

Linux FHS est basé sur ce que Sun et d’autres sociétés UNIX ont décidé à la fin des années 1980.

Un changement important à cette époque consistait à abandonner /usr/local/et à introduire /opt// { bin! lib! man! ...}

Si vous cherchez la raison pour laquelle / usr / bin est utilisé aujourd'hui comme dépotoir, je pense que GNOME est l'un des projets les plus responsables.

Ce qui est arrivé avec les bibliothèques 32 bits contre 64 bits semble être causé par FHS.

Solaris a introduit les sous-répertoires spécifiques à la plate-forme dans /lib /usr/binet /usr/lib. Souhaitez-vous comment Sun a amélioré le concept de base à partir de 1988?

Si chaque paquet avait sa propre partie du système de fichiers, vous auriez besoin de variables d'environnement extrêmement volumineuses et peu maniables PATH, LD_LIBRARY_PATHet similaires.

Vous pouvez bien sûr installer vous-même les paquetages de cette façon, puis utiliser quelque chose comme les modules GNU pour gérer s'ils sont dans votre environnement ou non, et c'est ce que nous faisons pour les logiciels scientifiques sur lesquels je travaille, mais nous ne le faisons pas pour logiciel système.