J'ai besoin de compiler un logiciel sur ma machine Fedora. Où est le meilleur endroit pour le mettre afin de ne pas interférer avec le logiciel fourni?
Réponses:
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.
/optsi vous effectuez l' sudoinstallation.
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.
/usr/local).
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
/etc/mysqlpour la configuration?
/usr/local/etcdossier par défaut, je suppose que je devrais l'utiliser ... :-)
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%.
/opt, mais j'ai souvent vu des objets /usr/localjonchées de junk provenant de la distro.
/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.
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.
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 ...
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.
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.
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.
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 :)
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.
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.
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.
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
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.
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.