Dois-je mettre l'application dans / usr / local ou / usr / local / share?

21

Quelles sont les "normes" - devrais-je mettre une application (pas seulement binaire, mais toute la distribution) vers / usr / local ou / usr / local / share.

Par exemple scala ou weka - il contient des exemples, des binaires, des bibliothèques, etc. Ce serait donc

/usr/local/scala-2.9.1

ou

/usr/local/share/scala-2.9.1

Comme je suis le seul administrateur, ce n'est pas un gros problème pour moi, mais je préfère utiliser quelque chose qui est largement utilisé, pas avec mes propres coutumes.

Important: je ne demande pas de renseignements sur les cas où vous devez diviser l'application en / usr / local / bin, / usr / local / lib et ainsi de suite. Je demande plutôt au sujet du cas où vous devez conserver un répertoire principal pour toute l'application.

software-installation directory-structure application

— greenoldman
source

6

Je pense que / opt est plus habituel dans ce genre de contexte.

— Faheem Mitha

@Faheem Mitha, très bon point. Grâce à vous, j'ai trouvé une telle explication "/ opt / 'provider' arborescence de répertoires, similaire à la façon dont Windows va installer de nouveaux logiciels dans sa propre arborescence de répertoires C: \ Windows \ Progam Files \" Program Name "de linuxtopia.org/ online_books / linux_beginner_books /… Pourriez-vous s'il vous plaît poster votre commentaire comme réponse, donc je le marquerais comme LA réponse? Merci.

— greenoldman

@greenoldman: veuillez également comprendre que conserver tous les fichiers dans un seul répertoire n'est pas la manière "standard" d'installer des applications sous Unix. /optest en effet la bonne réponse, mais elle n'est pas "largement utilisée" par les logiciels Unix / Linux traditionnels. Il y a de bonnes raisons de diviser vos fichiers en plusieurs répertoires, et aussi de les différencier /usrde/usr/local

— MestreLion

Par exemple, garder tous les exécutables de toutes les applications dans un seul /usr/bin(ou /usr/local/bin) permet à votre $ PATH d'atteindre tous les logiciels sans avoir besoin de le modifier pour chaque logiciel, un concept qui n'existe pas dans Windows

— MestreLion

19

Je pense que / opt est plus standard dans ce genre de contexte. La section pertinente de la norme de hiérarchie du système de fichiers est citée ci-dessous.

Les distributions peuvent installer des logiciels dans / opt, mais ne doivent pas modifier ou supprimer les logiciels installés par l'administrateur système local sans l'accord de l'administrateur système local.

Justification L'utilisation de / opt for add-on software est une pratique bien établie dans la communauté UNIX. L'interface binaire d'application System V [AT&T 1990], basée sur la définition d'interface System V (troisième édition), prévoit une structure / opt très similaire à celle définie ici.

La norme de compatibilité binaire Intel v. 2 (iBCS2) fournit également une structure similaire pour / opt.

Généralement, toutes les données requises pour prendre en charge un package sur un système doivent être présentes dans / opt /, y compris les fichiers destinés à être copiés dans / etc / opt / et / var / opt / ainsi que les répertoires réservés dans / opt.

Les restrictions mineures sur les distributions utilisant / opt sont nécessaires car des conflits sont possibles entre les logiciels installés et installés localement, en particulier dans le cas des chemins d'accès fixes trouvés dans certains logiciels binaires.

La structure des répertoires ci-dessous / opt / est laissée au conditionneur du logiciel, bien qu'il soit recommandé d'installer les packages dans / opt // et de suivre une structure similaire aux directives pour / opt / package. Une raison valable pour s'écarter de cette structure est pour les packages de support qui peuvent avoir des fichiers installés dans / opt // lib ou / opt // bin.

— Faheem Mitha
source

5

Vous ne devez utiliser que /usr/local/sharepour les fichiers qui ne sont pas spécifiques à une version particulière de l'architecture / du système d'exploitation.

Après cela, c'est à vous de décider si vous distribuez les fichiers entre les sous-répertoires existants de /usr/localou si vous créez un nouveau répertoire dédié dans /usr/local(mais ce dernier n'existera pas déjà sur l'exécutable PATH, le LD_LIBRARY_PATH, ni le MANPATH).

Jetez un œil au FHS

— symcbean
source

Merci. Donc, si c'est une analogie avec Windows, ce devrait être / usr / local / SPECIAL_APP et à l'intérieur il devrait y avoir ses sous-répertoires, non?

— greenoldman

@greenoldman: non. Aucune analogie s'adaptera parce que Windows et Linux utilisent différents modèles: Dans les fenêtres, vous gardez habituellement tous les fichiers dans un seul répertoire, où Linux vous les divisez généralement plus bin, share, lib, etc

— MestreLion

3

Jusqu'à ce qu'il /optdevienne courant, l'endroit habituel était /usr/local/lib/<package>.

— Teddy
source

1

D'après ce que j'ai lu, / opt est assez courant, mais n'est pas largement utilisé, mais ce n'est pas une surprise si vous pensez à la quantité de packages disponibles dans les référentiels.

— greenoldman

0

Lors de l'installation des applications locales, il existe plusieurs options selon la façon dont vous souhaitez accéder et mettre à jour. Il convient également de noter que certaines méthodes ressemblent davantage au système que vous avez déjà et que certaines sont plus ponctuelles. Je dirais que les «meilleures» solutions sont celles qui facilitent la gestion.

J'ai divisé cette réponse en fonction du nombre de packages pour lesquels effectuer des installations personnalisées. Le fractionnement est basé sur mes propres expériences. Ces expériences pèsent sur le temps nécessaire pour gérer les colis et les risques de gâcher quelque chose. Je ne veux pas dire que j'ai la connaissance de normes communes, mais je veux dire cela comme un point de référence à regarder lors de la prise de décision.

Pour seulement quelques packages , je voudrais mettre des packages supplémentaires /opt, où ils sont à l'écart de tout le reste afin que rien ne puisse les gâcher et qu'ils puissent gâcher autre chose. C'est la méthode que j'utilise sur mon NAS. Cette méthode garde cependant les binaires hors de votre PATH, vous devrez donc les ajouter manuellement. Cela fonctionne bien s'il n'y a que quelques packages à installer, mais devient un vrai gâchis s'il y en a beaucoup.

La mise à jour ici est assez facile car vous écrasez simplement le répertoire.

Avantages:

simple
rapide à configurer
aucune chance d'affecter d'autres parties du système
la désinstallation est aussi simple que l'installation

Les inconvénients:

Devient plutôt fastidieux si le nombre de packages à installer est important
Donne l' PATHair désordonné

Pour plus de quelques packages , je recommanderais d'utiliser le /usr/local/<your package>et la liaison sym de l'exécutable à partir de /usr/local/binou /usr/local/sbinselon si vous avez besoin des privilèges root. Cela vous évite de changer votre PATH chaque fois que quelque chose de nouveau est ajouté pour que le PATH reste propre. C'est la méthode que j'utilise sur mon ordinateur portable Arch pour tous les packages non pacman et les packages AUR.

La mise à jour se fait en écrasant le répertoire du package et en vérifiant que le lien symbolique est toujours valide et en corrigeant s'il ne l'est pas.

Avantages

Ne fait pas de PATHdésordre
N'affecte pas le système de base
Toujours très simple pour supprimer tous les modules complémentaires et revenir à un système de base propre

Les inconvénients:

Plus de travail à configurer
La suppression d'un seul paquet a quelques recherches à faire

Pour de nombreux packages . Comme ce n'est pas le cas que vous voulez, je serai bref. Je recommande le fractionnement du paquet dans bin, lib, share, etc. , et de les installer sur /usr/local. C'est pour garder la structure propre. Vous pouvez également spécifier qui peut écrire où et plus encore. Par exemple, vous ne voulez pas que des personnes autres que root modifient l'exécutable.

Ici, la mise à jour devient un peu plus délicate car vous devez écrire dans plusieurs répertoires. Je recommanderais d'emballer le tout et de laisser le gestionnaire de paquets s'occuper du reste.

Le partage

Le sharerépertoire est lui - même pour les fichiers indépendants de l' architecture comme indiqué dans Faheem de lien et les fichiers dépendants de l' architecture devrait aller lib, lib32, lib64, etc.

— Lauri Tšili
source

Donner des conseils en fonction du nombre de colis n'est pas utile; comment savoir à quel groupe appartient mon colis?

— Alois Mahdal

Aussi, quand vous dites "c'est recommandé", référencez la source ou dites clairement que c'est votre recommandation (je suppose que c'est la dernière ...?)

— Alois Mahdal

Et en passant, je ne vois pas comment dans / opt il y aurait moins de chance que les choses gâchent votre application que quand elle se propage à / usr etc. installer des scripts.

— Alois Mahdal

Il s'agit certainement de nommer qui fait que les choses se gâchent. C'est quelque chose que j'ai vécu dans le passé et c'est pourquoi j'aime garder mes paquets "supplémentaires" à l'écart de tout le reste. Je ne veux toujours pas que ça rende les choses laides.

— Lauri Tšili

Et oui, vous avez raison sur le "c'est recommandé" comme vous pouvez le voir dans ma réponse, j'ai utilisé "je recommanderais" partout ailleurs. J'ai maintenant corrigé mon orthographe et clarifié pourquoi je recommanderais quelque chose. Encore une fois, c'est juste mon point de vue et non pas comme une réponse définitive.

— Lauri Tšili