Où dois-je mettre les logiciels que je compile moi-même?

Réponses:

90

Règle générale, du moins sur les systèmes à l’architecture Debian:

  • /usr/localpour des choses qui est -ie « l' échelle du système » a /usr/localtendance à être dans le défaut d'un distro $PATH, et suit une hiérarchie de répertoires UNIX standard avec /usr/local/bin, /usr/local/libetc.

  • /optpour des choses que vous ne croyez pas pouvoir créer à l'échelle du système, avec des préfixes par application /opt/firefox-3.6.8, c'est-à-dire /opt/mono-2.6.7, et ainsi de suite. Les éléments ici nécessitent une gestion plus minutieuse, mais sont également moins susceptibles de casser votre système - et sont plus faciles à supprimer, car vous supprimez simplement le dossier et il est parti.

directhex
la source
Fait intéressant, de nombreux programmes / applications suggèrent automatiquement d'installer /optsi vous effectuez l' sudoinstallation.
HongboZhu
50

Si vous ne voulez vraiment pas que cela interfère, ne le placez pas dans votre ordinateur $PATH.

Si vous le voulez $PATH, assurez-vous au moins de ne pas l'installer /usr/local. J'ai constaté que beaucoup de logiciels y regardent même s'ils sont installés par la distribution /usr.

Ma méthode préférée pour installer un logiciel compilé sur mesure se trouve dans mon $HOMErépertoire. De cette façon, vous n’avez pas besoin d’utiliser sudoquoi que ce soit, et il est très bien séparé du reste de votre système. Par exemple:

mkdir ~/stage
./configure --prefix=/home/username/stage && make && make install

Et si vous le souhaitez, vous pouvez ensuite ajouter /home/username/stage/binà votre $PATH.

Sablonneux
la source
1
Définitivement, l’utilisation de votre répertoire personnel est la meilleure option. OMI.
bitek
1
+1 d'accord. J'aime ~ / sbin pour les scripts bash / ruby ​​/ python et ~ / opt / ... pour les installations compilées, avec des alias dans ~ / bin.
Kris
4
+1 pour utiliser votre répertoire personnel car cela simplifie les choses; -1 pour la suggestion d'éviter $ PATH - il existe en fait des répertoires "réservés aux installations locales" selon les normes (par exemple, /usr/local).
Riccardo Murri
1
Ma suggestion pour éviter / usr / local était basée sur le désir (plutôt vague) de l'affiche originale de ne pas interférer avec les logiciels fournis. Puisqu'il existe de nombreux logiciels fournis qui "aideront" en cherchant dans / usr / local ou dans $ PATH, j'ai pensé que cela pouvait être considéré comme une interférence. Mais cela dépend vraiment des besoins et des objectifs de chacun. / usr / local peut être un choix parfaitement judicieux dans de nombreuses situations.
Sandy
personne n'a remarqué l'incompréhension totale de la lettre "s" dans le commentaire n ° 2. qui devrait être supprimé
meffect
20

FHS dit de le mettre dans / usr / local où les distributions ne devraient pas le toucher. /usr/local/binpour les binaires /usr/local/srcde la source et /usr/local/libdes bibliothèques. Voir la spécification FHS pour plus d'informations

xénoterracide
la source
Qu'en est-il de la configuration? Disons que j'ai installé MySQL sans utiliser le gestionnaire de paquets, dois-je quand même utiliser /etc/mysqlpour la configuration?
Hubro
Je viens de remarquer qu'il y a un /usr/local/etcdossier par défaut, je suppose que je devrais l'utiliser ... :-)
Hubro
10

La plupart du temps, j'aime placer mes propres éléments compilés /opt. C'est une sorte d'endroit pseudo-standard. Vous pouvez également envisager /usr/local, mais je préfère garder mes affaires isolées à 100%.

Scott Anderson
la source
1
Les distributions ont tendance à mettre un certain nombre de choses dans / opt (généralement des paquets propriétaires) / opt ne dit pas que la distribution ne peut pas le toucher. Cependant, il dit que sur / usr / local
xenoterracide
1
Je n'ai jamais vu une distribution mettre des trucs /opt, mais j'ai souvent vu des objets /usr/localjonchées de junk provenant de la distro.
Scott Anderson
La distro que j'utilise aime mettre java dans / opt J'ai aussi vu Acrobat Reader. s'ils mettent des éléments dans / usr / local, ils ignorent FHS, qui dit qu'il faut éviter de les écraser dans les mises à jour du système.
xenoterracide
À chacun ses goûts, je suppose. FHS, c'est bien, mais je pense qu'on l'ignore parfois.
Scott Anderson
Les seules choses que j'ai jamais vues dans les paquets de distribution /usr/localétaient des hiérarchies de répertoires similaires à celles de l'arborescence standard, et peut-être des fichiers d'index pour des choses comme TeX.
Phil Miller
9

Mettez-les à /usr/local/src.

Ce que je fais est d'extraire la source dans ce répertoire. Cela créera un chemin comme

/usr/local/src/postgresql-8.3.7

Ensuite, je crée un lien symbolique:

/usr/local/src # ln -s  postgresql-8.3.7 postgresql

Faites tout votre bâtiment dans /usr/local/src/postgresql.

Faire les choses de cette façon aide quand vous avez besoin de passer d'une version à une autre et de documenter la version que vous utilisez.

Stephen Jazdzewski
la source
1
+1 pour indiquer votre justification et comment le PO peut l'appliquer, y compris la gestion des versions.
Samt
6

Cela me rappelle que je dois utiliser checkinstall plus souvent! Comme ça je fais juste comme d'habitude

 ./configure
 make

suivi par

 sudo checkinstall

créer un fichier .deb ...

Kevin Cantu
la source
2
Ne répond pas à la question.
JBentley le
5

S'il y a une possibilité - je suggérerais de compiler votre logiciel, puis de créer un package FC (je crois que c'est utiliser yum pour installer des packages logiciels). Ensuite, vous pouvez installer ce package de votre propre logiciel compilé et le supprimer sans endommager tout le système.

Eimantas
la source
5

Si vous voulez pouvoir installer et supprimer facilement plusieurs applications que vous avez construites vous-même, vous pouvez utiliser Stow comme simple gestionnaire de paquets.

Daniel James
la source
5

Selon le FHS , /usr/local/est utilisé pour les applications compilées à partir de la source, tandis que /opt/pour les applications tierces non prises en charge par le fournisseur de votre système d'exploitation.

Aaron Toponce
la source
4

Deux choses que je recommanderais:

À l'échelle du système: utilisez stow et installez sous / usr / local / stow / package-version. Ensuite, vous pouvez facilement basculer entre les versions.

Chez moi, ou si je n'ai pas les permissions d'écriture / usr / local, j'installe personnellement des programmes sous ~ / .local, ce qui est suggéré par le standard XDG .

Vous pouvez également utiliser stow localement, bien que je ne l'aie jamais fait :)

Elmarco
la source
3

J'ai une configuration un peu différente de celle de la plupart des gens car je développe beaucoup. J'ai un répertoire / home / jackson / bin / dans lequel j'installe des éléments et j'ai modifié mon .bashrc en ajoutant ceci:

export PATH=/home/jackson/bin/bin::$PATH
export LD_LIBRARY_PATH=/home/jackson/bin/lib:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=/home/jackson/bin/lib/pkgconfig:$PKG_CONFIG_PATH

Je ne ferais pas ça pour tout, mais c'est bien pendant le développement.

Jackson
la source
3

Il n'est en fait pas si difficile de créer des deb ou des rpm à partir d'une archive source. De cette façon, vous pouvez utiliser les installations du gestionnaire de paquets de votre distribution pour maintenir votre système propre. C’est ce que je fais la plupart du temps: il suffit de créer un petit nombre de tours.

wzzrd
la source
2

si vous compilez une application, vous pouvez ajouter son chemin d'accès aux exécutables dans votre variable d'environnement PATH. cela n'aura aucun impact sur les autres utilisateurs.

Hemant
la source
Je me demande pourquoi les votes négatifs? +1 au genre de "balance off"
phunehehe
Je me demande aussi pourquoi :-). J'ai utilisé la même solution pour utiliser cscope où je n'ai pas les autorisations d'installation.
Hemant
@phunehehe Probablement parce qu'il n'essaye même pas de répondre à la question. La question demande où placer le logiciel. Cette réponse donne un conseil sur ce que vous pourriez faire après l' avoir placée quelque part. Il pourrait être amélioré en donnant quelques suggestions sur les dossiers à utiliser.
JBentley le
2

Il y a toujours la possibilité de "le placer où il se doit" mais écrivez d'abord un simple rpm.

Nils
la source
1

Si vous souhaitez que votre application soit disponible pour tous les utilisateurs du système et que vous disposiez des autorisations nécessaires, utilisez / opt. Si vous souhaitez que l'application ne soit disponible que pour vous (et root), utilisez / home / nom d'utilisateur


la source
0

Le moyen le plus simple consiste à récupérer le paquet source ( .src.rpmpour RPMites), à le décompresser, à pirater la nouvelle source / configuration / quoi que ce soit dedans, à modifier la version de manière appropriée et à le construire. En installant cela, votre gestionnaire de paquets sera au courant du nouveau paquet, permettra de le considérer pour ses dépendances et de le désinstaller / mettre à jour.

C'est une corvée la première fois, mais si une nouvelle version (ou un correctif critique) est disponible, la mise à jour est alors plus simple. Un autre avantage est que vous pouvez créer votre propre référentiel avec un logiciel local, à partager par exemple par les machines d'un laboratoire.

vonbrand
la source
0

Ecrire un RPM, ce n'est pas difficile, a des directives sur l'endroit où placer les choses et rend la désinstallation en un tournemain.

Si vous faites cela, installez les fichiers sous /usret pas sous /usr/local, comme tous les autres fichiers qui passent par le système de conditionnement.

utilisateur55149
la source