Où installer les programmes dans Arch Linux?

Je suis pratiquement nouveau sur la scène Linux. J'ai récemment téléchargé Matlab pour l'installation. J'ai décompressé les fichiers et ai couru ./installpour lancer l'assistant. Alors que je progressais, il m’a demandé un chemin d’installation avec un défaut de /usr/local/Matlab. Ce premier abord ne semblait pas correct et semblait encore plus incorrect lorsque je regardais dans ce répertoire.

/usr/local/ a bin etc games include lib man sbin share src

Cela étant dit, il est peu probable que ce soit l'endroit le plus efficace pour installer un programme. Où sont installés la plupart des programmes? J'ai lu que cela dépend en grande partie de la version de Linux.

Des recommandations d'utilisateurs Linux expérimentés?

— sherrellbc
source

Vous pouvez installer une application dans le dossier de votre choix.

— Ramhound

Bien sûr, mais en termes de hiérarchie d'un système Linux, où cela aurait-il le plus de sens? Je ne pensais pas qu’avoir un Matlabrépertoire parmi les répertoires bin des bibliothèques avait beaucoup de sens.

— sherrellbc

/ usr / bin ou / usr / local / bin en tant qu'application installée par l'utilisateur

— EkriirkE

Il demande maintenant un chemin pour placer les liens symboliques vers les scripts Matlab. Aucune suggestion? J'ai installé Matlab à/usr/local/bin/Matlab

— sherrellbc

Il y a des conventions, mais à l'intérieur de celles-ci, c'est à vous de décider. Personnellement, je mets un logiciel propriétaire /opt. Vous pouvez probablement placer les liens symboliques n'importe où dans votre PATH.

— user55325

Il existe quelques emplacements pour les applications à installer dans Arch Linux:

pour les applications qui respectent la norme de hiérarchie des systèmes de fichiers et sont installées par le gestionnaire de packages système (dans le cas d'Arch pacman), une /usr/arborescence est utilisée. Les pièces les plus couramment utilisées par les applications sont:
- /usr/bin/ - c'est là que les fichiers binaires de l'application (exécutables) vont
- /usr/share/ - c'est là que vont les autres ressources de l'application (généralement du type immuable)
pour les applications qui suivent les principes FHS, mais qui sont installées à la main (généralement compilées makeet installées via make install), /usr/local/est le bon endroit. Ici, la hiérarchie imite celle de /usr/et son intention est de séparer les éléments installés manuellement des éléments de référentiel automatiques. Veuillez noter que si vous souhaitez conserver les packages locaux à jour et en installer beaucoup, utiliser AUR , un assistant AUR et apprendre à gérer les packages est probablement un meilleur moyen que de surpeupler /usr/local/.
Pour les applications qui ont une structure de dossiers plus monolithique (par exemple, Matlab), /opt/c'est le chemin à parcourir. Un général met juste les dossiers là, par exemple /opt/MonolithicApp/, /opt/Matlab/etc.
étant donné que les jeux ont tendance à avoir la structure de dossiers monolithique assez souvent, /usr/local/games/est un endroit désigné pour les mettre, en dehors de /opt/. Celui qui doit être utilisé est laissé à la discrétion de l'utilisateur.

Afin de rendre les choses pratiques, des ajouts $PATHsont nécessaires dans le cas de programmes installés dans /opt/. S'il y a un seul binaire, j'ai tendance à simplement créer un lien symbolique dans /usr/local/bin/.

S'il y a plus d'un / deux fichiers binaires, cela oblige à un PATH="$PATH:/opt/MonolithicApp/bin/"ajout quelque part dans les fichiers de configuration du shell.

Sources:

— Zaroth
source

Je reviens après quelques années d’utilisation de Linux. J'ai tendance à suivre cette convention et ça marche plutôt bien. Moi aussi, j'ai eu tendance à utiliser des liens symboliques pour appeler des fichiers binaires installés par l'utilisateur. Cependant, certains fichiers binaires supposent qu'ils sont appelés à partir de leurs répertoires racine. Pour résoudre ce problème, j’utilisais un simple script placé dans le répertoire racine de l’application (par exemple /usr/Matlab/matlab-start.sh) qui utilisait dirnameet realpathse cddirigeait vers le répertoire racine de l’app avant de passer $@à l’exécutable cible. Quelle est la convention pour les fichiers binaires dans la mesure /usr/binoù une localisation est également requise?

— sherrellbc le

Je ne suis pas sûr du type de fichiers binaires que vous voulez dire - les fichiers /usr/bindoivent y être placés uniquement par vos gestionnaires de paquets (par exemple, pacman, AUR helper) et un paquet correctement construit n'a pas d'exigence de "localisation", comme vous le dites. Peut-être qu'un exemple illustrant votre cas pourrait être utile?

— Zaroth