Garder une trace des programmes


33

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?


6
Est-ce que GNU Stow est une option ici? "GNU Stow est un programme permettant de gérer l’installation de progiciels en les séparant (par exemple, / usr / local / stow / emacs par rapport à / usr / local / stow / perl), tout en leur donnant l’impression d’être installés de la même manière. place (/ usr / local). "
Mike Renfro

@ Mike, ça a l'air très prometteur; J'aime l'idée d'activer et de désactiver les versions de programmes de manière transparente. Premièrement, quel est le programme actif et stable et à quelle fréquence un programme rompt-il le protocole de préfixe?
Will03uk

1
Ridiculement stable ( 1.3.2 date de 1996 et 1.3.3 jusqu'en 2002 ) et presque totalement inactif . C'est juste un script Perl qui gère les liens symboliques. Il était très difficile d’avoir des compilateurs et ce genre de choses dans la mémoire, mais pour les applications des utilisateurs finaux, tout s’est bien passé. Je l'ai utilisé pour toute application que je ne pouvais pas facilement supporter à partir de nouvelles versions de Debian ou dans l'un des référentiels de packages Solaris.
Mike Renfro

Réponses:


20

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.


4
Je pense que les choses ont peut-être un peu changé depuis le moment où cette réponse a été postée. En guise de mise à jour: GNU Stow prend actuellement en charge les listes ignorées, plusieurs répertoires de stockage, la détection préalable des conflits, etc. Je pense également que le stockage est en développement actif, tandis que Xstow n’a pas été mis à jour depuis environ 3 ans.
Amelio Vazquez-Reina

18

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.


C’est bien, mais j’utilise principalement les archives pour des programmes très actifs qui ne sont pas souvent fournis et la possibilité de basculer entre les versions cassées et non
stockées

Malheureusement, checkinstallsemble ne pas être activement maintenu (?) :-(
Nikos Alexandris

@ NikosAlexandris Je suis curieux de savoir si cela fonctionne comme prévu et si cela fonctionne bien - ce qui, en tant que non-utilisateur actuel, suppose-t-il - pourquoi est-il nécessaire qu'il soit activement maintenu?
Hashim

@Hashim je vois votre point. En dehors de la "pensée habituelle", cependant, un logiciel lié à la compilation d'un logiciel n'aurait-il pas besoin de maintenance, lorsque les compilateurs évoluent?
Nikos Alexandris

6

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.


6

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


3
  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).
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.