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.)