Quelle est la différence entre / opt et / usr / local?

Selon la norme de hiérarchie du système de fichiers , il /opts'agit de "l'installation de progiciels d'application complémentaires". /usr/localest "à utiliser par l'administrateur système lors de l'installation du logiciel localement". Ces cas d'utilisation semblent assez similaires. Les logiciels qui ne sont pas inclus dans les distributions sont généralement configurés par défaut pour être installés dans l'un /usr/localou l' autre, /optsans rime particulière ni raison pour laquelle ils ont choisi.

Y a-t-il une différence qui me manque ou les deux font-ils la même chose, mais existent-ils pour des raisons historiques?

Bien que les deux sont conçus pour contenir des fichiers ne faisant pas partie du système d'exploitation, /optet /usr/localne sont pas destinés à contenir le même ensemble de fichiers.

/usr/localest un emplacement pour installer les fichiers créés par l'administrateur, généralement à l'aide de la makecommande (par exemple, ./configure; make; make install). L'idée est d'éviter les conflits avec des fichiers faisant partie du système d'exploitation, qui pourraient être écrasés ou écrasés par des fichiers locaux sinon (par exemple, /usr/bin/foofait partie du système d'exploitation tout en /usr/local/bin/fooconstituant une alternative locale).

Tous les fichiers sous /usrpeuvent être partagés entre les instances de système d'exploitation, bien que cela soit rarement fait avec Linux. Ceci est une partie où la FHS est légèrement contradictoire, comme /usrdéfini en lecture seule, mais /usr/local/bindoit être en lecture-écriture pour que l'installation locale du logiciel réussisse. Le standard de système de fichiers SVR4, qui était la principale source d’inspiration de FHS, recommande d’éviter /usr/localet d’utiliser /opt/localplutôt pour surmonter ce problème.

/usr/localest un héritage de la BSD d'origine. À ce moment-là, le code source des /usr/bincommandes du système d' exploitation se trouvait dans /usr/src/binet /usr/src/usr.bin, tandis que la source des commandes développées localement se trouvait dans /usr/local/srcet leurs fichiers binaires dans /usr/local/bin. Il n'y avait aucune notion d'emballage (en dehors des archives).

D'autre part, /optest un répertoire pour l'installation de packages non groupés (c'est-à-dire que les packages ne font pas partie de la distribution du système d'exploitation, mais fournis par une source indépendante), chacun dans son propre sous-répertoire. Ils constituent déjà des packages complets fournis par un distributeur de logiciels tiers indépendant. Contrairement aux /usr/localchoses, ces paquets respectent les conventions de répertoires (ou du moins ils le devraient). Par exemple, someappserait installé dans /opt/someapp, avec l'une de ses commandes /opt/someapp/bin/foo, son fichier de configuration /etc/opt/someapp/foo.conf, ainsi que ses fichiers journaux /var/opt/someapp/logs/foo.access.

La différence fondamentale réside dans le /usr/localfait que les logiciels ne sont pas gérés par le gestionnaire de programmes, mais respectent néanmoins les règles de déploiement Unix standard.

C'est pourquoi vous avez /usr/local/bin, /usr/local/sbin /usr/local/includeetc ...

/optd'autre part, c'est un logiciel qui ne suit pas cela et qui est déployé de manière monolithique. Cela inclut généralement des logiciels commerciaux et / ou multiplates-formes présentés dans le style "Windows".

Ils sont très similaires et l’utilisation de l’un ou de l’autre est plus une question d’opinion. Le journal Linux a eu cette discussion point / contrepoint sur ce sujet précis ici .

Pour moi, personnellement, c'est ce que Bill a dit dans le lien de @ philfr:

Sur un système de développement, ou un bac à sable, disposer d'un répertoire / opt où vous pouvez simplement lancer des éléments et voir s'ils fonctionnent est d'une grande utilité. Je sais que je ne vais pas faire l'effort d'emballer les choses moi-même pour les essayer. Si l'application ne fonctionne pas, vous pouvez simplement entrer le répertoire / opt / mytestapp et cette application appartient à l'historique. L'emballage peut avoir du sens lorsque vous exécutez un déploiement volumineux (parfois, je fais des applications en package), mais souvent, il est agréable d'ajouter des éléments dans / opt.

Malheureusement, la plupart des make installscripts insèrent des fichiers au /usr/locallieu de simplement créer un lien symbolique: - /

Premièrement, je ne pense pas qu'il y ait une réponse stricte; différents administrateurs auront des opinions différentes, en fonction de leurs antécédents. Historiquement, /usr/localest venu en premier; c'était la convention à Berkley, IIRC. À un moment donné au cours du développement de System V, si je ne me trompe pas (tout cela remonte à longtemps et je n'ai pas pris de notes), il y a eu une décision ou un désir de pouvoir monter en /usrlecture seule, ce qui signifiait que vous ne pouviez pas ajouter de nouveau logiciel; c'est peut-être pour cette raison qu'il a /opt été inventé. En l'occurrence, il y avait tellement de logiciels existants qui écrivaient /usrque cette idée n'avait jamais vraiment pris forme.

Ma préférence personnelle est /opt, avec un sous-répertoire distinct pour chaque produit; cela facilite la suppression d'un produit rm -fr. Mais si tout votre logiciel est installé via un bon gestionnaire de paquets, peu importe, et si le logiciel que vous installez ne respecte pas strictement ces conventions, et écrit des configurations, etc. /usr, cela n'a pas d'importance, bien que pour les raisons opposées.

J'ai un point de vue légèrement différent sur cette question.
Bien que la réponse de jlliagre soit correcte, l’application pratique pour moi, lors du déploiement de logiciels dans un cluster, se résume aux variables d’environnement par défaut et à la réutilisation par défaut des bibliothèques.

En termes simples - /usr/localet tous ses répertoires enfants se trouvent dans les variables env appropriées, telles que PATHet MANPATH, et se /usr/local/lib{,64}trouvent dans ldconfig's ( /etc/ld.so.conf.d/).

/opt/OTOH n’est pas - ce qui est avantageux à la fois lorsque plusieurs versions ou des packages en conflit sont nécessaires pour coexister dans le système, mais nécessite une sorte de gestion de l’environnement (par exemple, des modules d’environnement ou des collections de logiciels ), et désavantageux dans le sens où cela risquerait de "gaspiller "espace de stockage en dupliquant les bibliothèques partagées, chaque installation /optpouvant être complètement autonome.

Pour que la nature partagée /usr/localfonctionne /usr/local/bincorrectement , on suppose par exemple que les fichiers binaires sont installés directement sur (et les pages de manuel sur appropriées /usr/local/share/man/...) plutôt que sur /usr/local/app/{bin,share/man,...}etc.