Pourquoi le logiciel s'installe-t-il dans / usr / lib?

11

J'utilise des serveurs Linux depuis des années maintenant et je continue d'être confus par le Filesystem Hierarchy Standard. Habituellement, je peux vivre avec la confusion. Mais maintenant que je développe mon propre logiciel pour Linux, je dois comprendre où il est censé être installé par les gestionnaires de paquets.

J'étais assez convaincu que / opt était l'endroit parfait pour mon application. Mais après avoir enquêté sur mon système de fichiers Debian, je n'en suis plus sûr: beaucoup de logiciels sont en fait installés dans / usr / lib! Pour n'en nommer que quelques-uns: MySQL, MySQLWorkbench, Nautilus, Rythmbox ...

Selon le FHS, / usr / lib est censé contenir des "bibliothèques de programmation et de packages" et "inclut des fichiers objets, des bibliothèques et des binaires internes qui ne sont pas destinés à être exécutés directement par les utilisateurs ou des scripts shell" ( voir ici ).

Beaucoup de logiciels situés dans / usr / lib de mon serveur Debian ne sont pas des bibliothèques ou des binaires internes mais des logiciels exécutables à part entière!

Je suis toujours sur la bonne voie pour installer mon application dans / opt. Mais je voudrais vraiment comprendre si c'est correct et, surtout, pourquoi .

Merci d'avance pour vos aimables conseils,

Eric.

Eric MORAND
la source
2
Vérification ponctuelle, d'après ce que je peux dire, MySQLWorkbench installe uniquement les bibliothèques sous / usr / lib. Qu'est-ce qui vous fait penser qu'il existe un "logiciel exécutable utilisateur complet" dans / usr / lib?
Mark Wagner
Le raccourci réel situé dans le menu Application pointe vers un binaire situé dans / usr / lib, si je me souviens bien.
Eric MORAND
Vous semblez confus quant à l'emplacement d'installation du logiciel que vous avez indiqué. Voici les liens vers les listes des fichiers pour MySQL et Nautilus. Notez que les fichiers sont répartis entre / etc, / usr / bin, / usr / lib etc., tout comme FHS le dit. packages.debian.org/wheezy/i386/mysql-server-5.5/filelist packages.debian.org/wheezy/i386/nautilus/filelist
sciurus

Réponses:

6

La vraie clé pour comprendre la norme de hiérarchie du système de fichiers est de savoir qu'elle est conçue en pensant aux systèmes de fichiers réseau.

Pour chaque machine du même système d'exploitation, de la même version et de la même architecture, vous pouvez partager / usr via NFS et le monter.
/ usr est (re) monté après l'initialisation de la pile réseau.

/var <-- local, r/w optimized
/usr <-- can be mounted over network, possibly even read-only!
/opt <-- local, read mostly
/etc <-- local, read mostly
/srv <-- local, r/w optimized

/home <-- either/or
Dan Garthwaite
la source
Pourriez-vous fournir un lien vers les normes locales / distantes et r - r / w?
Captain Giraffe
Est-ce à dire que l'on peut avoir un seul "référentiel" / usr pour chaque serveur ou poste de travail Linux d'un réseau?
Eric MORAND
1
Cela demande du travail, mais oui, vous le pouvez. À l'époque où les disques durs étaient chers, c'était la norme pour tout déploiement important.
Dan Garthwaite
@ eric-morand Du FHS: "/ usr est la deuxième section principale du système de fichiers. / usr est des données partageables en lecture seule. Cela signifie que / usr doit être partageable entre divers hôtes conformes FHS et ne doit pas être écrit sur . Toute information propre à l'hôte ou variant avec le temps est stockée ailleurs. " pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
Dan Garthwaite
Oups. Le commentaire ci-dessus était pour @CaptainGiraffe
Dan Garthwaite
12

La différence est qu'il /usrest destiné à contenir les packages installés dans le cadre du système . Les paquets que vous obtenez des dépôts Debian / Ubuntu, PPA, etc., allez ici. While /optest destiné aux applications tierces dégroupées qui ne sont pas distribuées via le processus de distribution des packages de distribution.

Si vous distribuez des packages .deb ou .rpm, en vue de l'inclusion éventuelle de votre logiciel dans les référentiels officiels, vous devez installer sur /usr. Sinon installez à /opt. Dans les deux cas, votre application doit pouvoir être compilée pour s'exécuter dans n'importe quel emplacement arbitraire (par exemple à l'aide des outils automatiques GNU).

Michael Hampton
la source
Merci. Pour l'instant, je n'ai pas l'intention d'inclure mon application dans le référentiel officiel.
Eric MORAND
Qu'en est-il de / usr / local, alors? Ou est-ce discret
Aaron Copley
@AaronCopley /usr/localn'était pas dans la portée de cette question. Mais il est destiné aux logiciels tiers que l'administrateur local compile et installe.
Michael Hampton
C'est pourquoi j'ai demandé si cela serait considéré comme discret.
Aaron Copley
2

Vous installez vos bibliothèques dans <prefix>/lib, vos fichiers binaires dans <prefix>/bin, vos fichiers d'en-tête dans <prefix>/include, les pages de manuel dans prefix/[share/]man, les fichiers pkgconfig dans <prefix>/lib/pkgconfigou <prefix/share/pkgconfig, vos fichiers cmake .m4 dans<prefix>/share/aclocal

Laissez ensuite le gestionnaire de packages décider du préfixe. Si vous distribuez vous-même les rpm / deb, /usrc'est un bon choix pour un préfixe.

./configure --prefix=~/.local/ Cela devrait toujours fonctionner, alors n'allez pas coder en dur votre chemin n'importe où s'il vous plaît!

Certaines bibliothèques sont enveloppées dans un autre outil qui les rend également exécutables et utilisables en tant que bibliothèque, mais ce sont toujours des bibliothèques, et non dans votre $ PATH, donc il est correct de les mettre dans / lib je suppose.

Jens Timmerman
la source
1

Je suggérerais d'éviter d'installer votre application sous / opt. Raison 1: certaines distributions n'ont pas / opt par défaut Raison 2: / usr / lib est un chemin standard pour les bibliothèques {Si d'autres applications doivent utiliser votre bibliothèque, vous devez ajouter votre chemin de bibliothèque manuellement dans / etc / ldconfig} / opt est plus pratique lorsque vous avez des applications autonomes que vous installez manuellement et que vous voulez savoir où elles se trouvent

L'une des raisons pour lesquelles les exécutables à part entière sont situés sous / usr / lib pourrait être qu'ils sont utilisés à partir d'autres scripts. {Par exemple, les scripts bash ne peuvent pas utiliser directement une API. pour cette raison, une astuce courante consiste à construire un "wrapper" autour de cette API et à pousser les paramètres comme arguments de script}

Nikolaidis Fotis
la source
2
Je ne suis pas d'accord. S'il veut installer dans / opt, le gestionnaire de paquets créera le répertoire, donc ce n'est pas un problème. De plus, les binaires installés dans / usr / lib sont une mauvaise idée.
Walter
Merci @Nikolaidis Fotis. Mais dans mon cas, mon application ne contient pas de bibliothèque publique et ne sera pas utilisée par d'autres applications.
Eric MORAND
0

Veuillez l'installer dans / opt.

Beaucoup trop d'applications Linux font la même marque que les développeurs Windows dans les années 90.

Permet d'installer nos trucs dans C: \ windows afin qu'il soit simple et facile à trouver (et légèrement plus rapide). Puis sont venues 15 ans d'enfer sur les DLL car différents progiciels avaient besoin de différentes versions des mêmes bibliothèques (qui, dans Windows, n'avaient pas de version des bibliothèques).

Sauf si vous écrivez un logiciel système réel, mettez-le dans / opt, afin que les gens puissent mieux suivre qui a installé quoi.

Walter
la source
4
Ce n'est pas Windows. Nous avons des gestionnaires de packages qui fonctionnent et ce n'est vraiment pas vraiment un problème.
Michael Hampton
Si vous êtes vraiment inquiet que tout soit dans la même arborescence, consultez le gestionnaire de paquets Nix . Le meilleur des deux mondes, si vous me demandez.
TheSola10