Effet de la compilation à partir de la source sur les applications déjà installées

J'utilise Ubuntu 12.04. Disons que j'ai installé à package xpartir du référentiel (avec toutes ses dépendances) à la version 1.7 mais j'ai besoin de certaines fonctionnalités qui ne sont disponibles que dans la version 1.8, alors je télécharge le tar source et le compile:

./configure  
make  
make install

• Cela remplace-t-il les binaires 1.7 existants?
• Si les fichiers binaires existants sont remplacés, le gestionnaire de packages reflète-t-il la nouvelle version (1.8) et peut-il package xêtre mis à jour par le gestionnaire de packages à l'avenir?
• Si package ya une dépendance de package x 1.8- sera-t-elle satisfaite?

J'ai essayé de trouver une bonne source en ligne qui explique cela. Si vous avez des recommandations, faites-le moi savoir.

La grande majorité des .debpackages, qu'ils soient fournis ou non par des référentiels officiels, s'installent avec le préfixe /usr.

Cela signifie que les exécutables destinés à être exécutés par l'utilisateur entrent /usr/binou /usr/sbin(ou /usr/gamess'il s'agit d'un jeu), les bibliothèques partagées entrent /usr/lib, les données partagées indépendantes de la plate-forme entrent /usr/share, les fichiers d' en -tête entrent /usr/includeet le code source installé entre automatiquement /usr/src.

Un petit pourcentage de packages utilise /comme préfixe. Par exemple, le bashpackage place l' bashexécutable /bin, non /usr/bin. Ceci est pour les paquets qui fournissent l'essentiel de fonctionner en mode mono-utilisateur (tel que le mode de récupération) et pour démarrer le mode multi-utilisateur (mais rappelez - vous, qui inclut souvent la fonctionnalité de monter certains types de partages réseau ... dans le cas /usrest un système de fichiers distant).

Un petit pourcentage de .debpackages, principalement ceux créés avec Quickly , créent un dossier spécifique au package à l'intérieur /optet y placent tous leurs fichiers. En dehors de cela, la plupart du temps /optest l'emplacement utilisé par le logiciel installé à partir d'un programme d'installation exécutable qui n'utilise pas le gestionnaire de packages du système mais n'implique pas de compilation à partir de la source. (Par exemple, si vous installez un programme propriétaire comme MATLAB, vous le mettrez probablement /opt.)

Contrairement à tout cela, lorsque vous téléchargez une archive source (ou obtenez du code source à partir d'un système de contrôle des révisions tel que Bazaar ou git), que vous la construisez et l'installez, elle s'installe généralement avec le préfixe /usr/local(sauf si vous lui dites de le faire autrement). Cela signifie que vos exécutables entrent dans /usr/local/bin, /usr/local/libou /usr/local/games, vos bibliothèques dans /usr/local/lib, et ainsi de suite.

Il y a quelques exceptions à cela - certains programmes, par défaut, s'installent au /usrpréfixe et écraseraient ainsi les installations des mêmes programmes à partir des .debpackages. En règle générale, vous pouvez empêcher cela en exécutant ./configure --prefix=/usr/localau lieu de ./configurelorsque vous les créez. J'insiste à nouveau sur le fait que ce n'est généralement pas nécessaire.

(C'est pour cette raison qu'il est très judicieux pour vous de mettre le code source que vous construisez et installez pour une utilisation à l'échelle du système /usr/local/src, qui existe à cette fin.)

En supposant que la version packagée est installée dans /usret que la version que vous avez installée à partir de la source se trouve dans /usr/local:

• Les fichiers du package installé ne seront pas écrasés.

  En règle générale, la version la plus récente s'exécute lorsque vous appelez manuellement le programme à partir de la ligne de commande (en supposant que /usr/local/binou là où les exécutables sont installés se trouve dans votre PATHvariable d'environnement et apparaît avant le /usrrépertoire -prefixé correspondant , par exemple /usr/bin).

  Mais il peut y avoir des problèmes avec les lanceurs créés et rendus accessibles via les menus ou la recherche. De plus, si vous avez installé plus d'une version d'une bibliothèque à différents endroits, il peut devenir un peu plus compliqué de déterminer laquelle sera utilisée par quel logiciel.

  Si vous n'êtes pas réellement en utilisant les deux versions du programme ou de la bibliothèque, puis souvent vous devez supprimer celui que vous ne l' utilisez, bien que dans certaines situations , vous pouvez garder un paquet installé pour satisfaire les dépendances.

Cependant, si pour une raison quelconque, les fichiers sont remplacés (par exemple, si le code source est installé dans /usrplutôt que /usr/local):

• Le gestionnaire de packages ne saura rien sur la façon dont le logiciel qu'il a installé a été modifié. Il pensera que l'ancienne version est installée. De mauvais problèmes peuvent en résulter. Vous devez éviter cela. Si vous avez créé cette situation, vous devez désinstaller le logiciel que vous avez installé à partir de la source (généralement sudo make uninstalldans le répertoire), puis désinstaller le ou les packages qui fournissent les fichiers qui ont été remplacés (car ils ne seront pas restaurés en désinstallant la version installée). de la source). Réinstallez ensuite la version que vous souhaitez avoir./usr/local/src/program-or-library-name

Quant à l'accomplissement des dépendances:

• S'il existe un .debpackage qui dépend du logiciel que vous avez installé à partir de la source et qui nécessite la version que vous avez installée à partir de la source (ou supérieure), ce package ne sera pas installé avec succès. (Ou, pour être plus précis, vous pouvez peut-être "l'installer" mais il ne sera jamais "configuré", vous ne pourrez donc pas l'utiliser.) Les dépendances sont résolues par les versions des packages installées, et non par quel logiciel vous avez réellement.

  De même, le logiciel tentera au moins de s'installer complètement même si vous avez supprimé manuellement les fichiers fournis par les packages dont dépend le logiciel en cours d'installation. (Vous ne devriez généralement pas essayer d'exploiter cela à quelque fin que ce soit. Le gestionnaire de paquets fonctionnant sur la base de fausses informations est presque toujours une mauvaise chose.)

Par conséquent, si vous ne trouvez pas un package qui fournit la version du logiciel dont vous avez besoin, vous devrez peut-être créer votre propre .debpackage à partir du logiciel que vous avez compilé et installer à partir de ce package. Le gestionnaire de paquets saura alors ce qui se passe. La création d'un package pour votre propre usage, dont vous n'avez pas besoin pour bien fonctionner sur les ordinateurs d'autres personnes, n'est en fait pas très difficile. (Mais je pense que cela peut être hors de la portée de votre question, telle qu'elle est actuellement libellée.)

Ce que vous installez à partir du centre logiciel ou avec une commande APT ( apt-get, aptitude) ou avec dpkgest connu du système de gestion des packages. dpkgest l'outil de manipulation de package de bas niveau, APT et ses amis sont des outils de niveau supérieur qui invoquent dpkgpour effectuer l'installation réelle et également gérer les dépendances et les téléchargements de packages.

Si vous compilez un programme à partir des sources, il ne sera pas connu du gestionnaire de packages. La convention sur Linux, que vous devez suivre sous peine d'avoir du mal à suivre les choses et à faire remplacer vos installations, est la suivante:

• /bin, /lib, /sbin, /usrSont réservés au gestionnaire de paquets;
• sauf /usr/localpour l'administrateur système - respectez la hiérarchie des répertoires, mais vous êtes seul pour gérer les fichiers.

Voir Meilleur moyen de mettre à niveau vim / gvim vers 7.3 dans Ubuntu 10.04? pour une liste des moyens d'obtenir des versions plus récentes du logiciel. Le plus simple est d'obtenir un AAE , s'il y en a un. Si vous obtenez un package binaire ou compilez à partir des sources, je vous recommande d'utiliser stow pour gérer votre logiciel installé manuellement. Alternativement, créez votre propre .debpackage - c'est plus de travail, mais cela rapporte si vous effectuez une mise à niveau fréquente (refaire généralement le package pour la prochaine version mineure est très rapide) ou si vous déployez sur de nombreuses machines exécutant la même distribution.

Avec la plupart des programmes, si vous exécutez ./configure && make && sudo make install, le programme est installé sous /usr/local. Vérifiez la documentation fournie avec la source (généralement dans un fichier appelé READMEou INSTALL) ou exécutez ./configure --helppour vérifier que c'est le cas. Si le programme est installé sous /usr/local, il n'interférera pas avec la version fournie par le gestionnaire de paquets. /usr/local/binvient en premier sur le système PATH. Notez que vous devrez exécuter en make installtant qu'administrateur (root); ne compilez pas en tant que root. Comme indiqué ci-dessus, je recommande d'utiliser stow au lieu de l'installer directement dans /usr/local.

Cela dépend du paquet et de beaucoup d'autres choses

1. conventions de dénomination utilisées - le binaire contient-il des numéros de version dans les noms de fichiers
2. emplacement d'installation - est-ce par défaut dans opt, mais la version packagée est dans / usr
3. beaucoup plus de possibilités

Pour faire court: il
n'y a pas de réponse générique. Cela dépend fortement du package. Vous devez utiliser des PPA +1 officiels si possible, par opposition à la compilation à partir de la source.