Garder une trace des programmes

Lorsque j'installe un programme simple, il utilise souvent make && make installet même rarement une cible de désinstallation .

Si je souhaite mettre à niveau un programme, est-ce un protocole standard de supposer qu'il réécrit de manière transparente sur l'ancien programme?

Comment puis-je suivre ces programmes? Est- ce que la plupart des gens se contentent de "tirer et d'oublier" et si aucune cible de désinstallation n'est spécifiée, dois-je tout supprimer manuellement?

Installez chaque programme dans une arborescence de répertoires dédiée et utilisez Stow ou XStow pour que tous les programmes apparaissent dans une hiérarchie commune. Stow crée des liens symboliques du répertoire spécifique au programme vers une arborescence commune.

Plus en détail, choisissez un répertoire de niveau supérieur, par exemple /usr/local/stow. Installez chaque programme sous /usr/local/stow/PROGRAM_NAME. Par exemple, organisez l’installation de ses exécutables /usr/local/stow/PROGRAM_NAME/bin, de ses pages de manuel /usr/local/stow/man/man1, etc. Si le programme utilise autoconf, lancez-le ./configure --prefix /usr/local/stow/PROGRAM_NAME. Après avoir couru make install, lancez stow:

./configure --prefix /usr/local/stow/PROGRAM_NAME
make
sudo make install
cd /usr/local/stow
sudo stow PROGRAM_NAME

Et maintenant, vous aurez des liens symboliques comme ceux-ci:

/usr/local/bin/foo -> ../stow/PROGRAM_NAME/bin/foo
/usr/local/man/man1/foo.1 -> ../../stow/PROGRAM_NAME/man/man1/foo.1
/usr/local/lib/foo -> ../stow/PROGRAM_NAME/lib/foo

Vous pouvez facilement suivre les programmes que vous avez installés en listant le contenu du stowrépertoire. Vous savez toujours à quel programme appartient un fichier, car il s'agit d'un lien symbolique vers un emplacement situé dans le répertoire de ce programme. Désinstallez un programme en exécutant stow -D PROGRAM_NAMEpuis en supprimant le répertoire du programme. Vous pouvez rendre un programme temporairement indisponible en le lançant stow -D PROGRAM_NAME(exécutez-le stow PROGRAM_NAMEpour le rendre à nouveau disponible).

Si vous voulez pouvoir basculer rapidement entre les différentes versions du même programme, utilisez-le /usr/local/stow/PROGRAM_NAME-VERSIONcomme répertoire du programme. Pour mettre à niveau de la version 3 à la version 4, installez la version 4, puis exécutez-la stow -D PROGRAM_NAME-3; stow PROGRAM_NAME-4.

Les anciennes versions de Stow ne vont pas très loin au-delà des bases décrites dans cette réponse. Les versions plus récentes, ainsi que XStow (qui n’a pas été maintenue récemment) ont des fonctionnalités plus avancées, telles que la possibilité d’ignorer certains fichiers, de mieux gérer les liens symboliques existants en dehors du répertoire de stockage (tels que man -> share/man), de gérer automatiquement certains conflits (lorsque deux les programmes fournissent le même fichier), etc.

Si vous n'avez pas ou ne voulez pas utiliser un accès root, vous pouvez choisir un répertoire dans votre répertoire personnel, par exemple ~/software/stow. Dans ce cas, ajoutez ~/software/binà votre PATH. Si vous manne trouvez pas automatiquement les pages de manuel, ajoutez-les ~/software/manà votre MANPATH. Ajoutez ~/software/infoà votre INFOPATH, ~/software/lib/pythonà votre PYTHONPATH, et ainsi de suite, le cas échéant.

Vous pouvez utiliser checkinstall pour créer un paquet (paquets compatibles RPM, Deb ou Slackware). Ainsi, vous pouvez utiliser votre gestionnaire de paquets distros pour ajouter / supprimer l'application (mais pas la mise à jour).

Vous utilisez checkinstallà la place de la make installcommande (en utilisant le paramètre -D pour Deb; -R est RPM et -S est Slackware):

root@nowhere# ./configure
root@nowhere# make
root@nowhere# checkinstall -D

checkinstall construira et installera le paquet par défaut, ou vous pourrez le construire uniquement sans installer.

checkinstall est disponible dans la plupart des référentiels de distributions.

Pour l’essentiel, c’est la raison pour laquelle les packages, les ports et d’autres types de gestionnaires empêchent ce genre de choses de se produire.

Je dirais que la suppression manuelle est le seul moyen de procéder à une installation manuelle, à moins que quelqu'un d'autre ait une meilleure réponse à ce point que je ne connais peut-être pas.

Une autre alternative est d' utiliser les astuces Linux From Scratch :

Plus de contrôle et de gestion des packages à l'aide des utilisateurs de packages

3 Utilisateurs du paquet
3.1 Introduction

L'idée de base de ce schéma s'explique facilement. Chaque paquet appartient à un certain "utilisateur de paquet". Lorsque vous installez un package, vous créez et installez le package en tant qu'utilisateur de ce package. Tous les fichiers installés sont la propriété de l'utilisateur du package. En conséquence, toutes les tâches habituelles de gestion des paquets peuvent être facilement réalisées grâce à l'utilisation d'utilitaires de ligne de commande standard. Un simple ls -l <file>message vous indiquera, par exemple, à quel paquet <file>appartient le paquet et une find -user ...commande vous permet d'effectuer une opération sur tous les fichiers appartenant à un certain paquet, par exemple de les supprimer pour désinstaller le paquet.

Mais la gestion des paquets n'est pas tout ce pour quoi les utilisateurs de paquets sont bons. Étant donné que les utilisateurs de package ne disposent pas de droits root, l'installation d'un package est limitée dans ses possibilités. Par exemple, un utilisateur de package n'a pas le droit de remplacer les fichiers d'un autre utilisateur. Les conflits entre différents packages qui souhaitent installer un fichier binaire, une bibliothèque ou un fichier d'en-tête du même nom sont plus fréquents que vous ne le pensez. Avec les utilisateurs du package, vous ne courez jamais le risque que l’installation du package B détruise les fichiers du package A en silence, sans que vous ne le remarquiez. Toute tentative en ce sens lors de l'installation du package B provoquera l'erreur "Autorisation refusée" ou "Opération non autorisée", ce qui vous permettra de prendre les mesures appropriées. Une autre chose que les utilisateurs de packages ne sont pas autorisés à faire est d'installer les fichiers binaires setuid root. La décision de créer une racine setuid binaire est également quelque chose qu'un administrateur prudent ne veut pas laisser au créateur d'un progiciel.

En règle générale, les comptes d'utilisateur de package n'ont pas de mot de passe valide. Seul su un utilisateur de package peut donc y accéder par la racine , ce qui garantit que les utilisateurs de package ne s'ouvrent pas de manière supplémentaire dans le système et nuisent à la sécurité. Mais vous pouvez quand même définir des mots de passe pour permettre à un co-administrateur à qui vous voulez installer et maintenir certains progiciels de le faire sans avoir accès au compte root réel. Ce co-administrateur pourrait par exemple installer, supprimer, modifier des bibliothèques supplémentaires éventuellement nécessaires à son groupe de travail. Il serait toutefois incapable de supprimer ou de modifier des bibliothèques qui ne lui appartiennent pas, telles que libc.

Après cette première suggestion grossière, j'ai trouvé une variante évoluée:

crablfs - Système de gestion de paquets basé sur l'utilisateur

Ceci crablfsest le dernier exemple de gestion de paquets utilisant des uids et des gids uniques pour la gestion des paquets, mais sur sourceforge, il évolue à nouveau dans ulfs:

uLFS: votre Linux From Scratch gérable et réutilisable

Pour les utilisateurs causaux des paquets installés, je pense que la solution LFS "paquet d'utilisateurs" est légère, moins invasive et élégante. En bref, vous installez des packages dans /usr/localou /home/user/localsuivez les fichiers en utilisant des uids et des gids uniques pour chaque package, mais placez tous les fichiers dans des emplacements traditionnels, des répertoires communs /usr/local/bin, /usr/local/libcomme dans toutes les distributions Linux classiques ... occlusion et suppression ou suppression non désirée de fichiers est évité par une astuce Linux expliquée par Matthias S. Benkmann dans more_control_and_pkg_man.txt qui nécessite uniquement la manipulation des autorisations de fichiers et de répertoires normaux, par exemple l’autorisation «sticky bit» pour les répertoires afin d’éviter les écrasements de fichiers non désirés:

3.3 Groupes

Chaque utilisateur du package appartient à au moins 2 groupes. L'un de ces groupes est le groupe "install", auquel tous les utilisateurs du package (et uniquement les utilisateurs du package) appartiennent. Tous les répertoires dans lesquels les packages sont autorisés à installer des éléments appartiennent au groupe d'installation. Cela inclut les répertoires tels que / bin et / usr / bin mais exclut les répertoires tels que / root ou /. Les répertoires appartenant au groupe d'installation sont toujours inscriptibles par groupe. Cela serait suffisant pour les aspects de gestion de paquets, mais sans préparation supplémentaire, cela ne donnerait pas davantage de sécurité ou de contrôle car chaque paquet pourrait remplacer les fichiers d'un paquet différent (la modification serait visible dans la sortie dels -l, bien que). Pour cette raison, tous les répertoires d'installation ont l'attribut sticky. Cela permet aux utilisateurs de créer de nouveaux fichiers et de supprimer ou de modifier leurs propres fichiers dans le répertoire, mais les fichiers des autres utilisateurs ne peuvent être ni modifiés ni supprimés. Dans la suite de cette astuce, chaque fois que le terme "répertoire d'installation" est utilisé, il fait référence à un répertoire appartenant au groupe d'installation, est inscriptible du groupe et persistant. IOW, à transformer <dir>en un répertoire d'installation que vous feriez

chgrp installer && chmod g + w, o + t

Pour moi, cela ressemble à une solution simple et intelligente! J'ai utilisé ce schéma dans ma construction LFS et c'est une solution qui fonctionne ...

1. Vous pouvez créer un RPM vide pour rappel.
2. Vous pouvez envisager d’emballer le logiciel correctement dans un RPM.
3. Vous pouvez laisser une copie des tarfichiers de l'installation /usr/src/non-rpmsà vous rappeler (c'est ce que je fais habituellement).