Programme verfolgen

Wenn ich ein einfaches Programm installiere, wird häufig make && make installein Deinstallationsziel verwendet und häufig auch nicht .

Wenn ich ein Programm aktualisieren möchte, ist es ein Standardprotokoll, davon auszugehen, dass es nur nahtlos über das alte Programm geschrieben wird?

Wie verfolge ich diese Programme? Müssen die meisten Leute einfach "feuern und vergessen" und wenn kein Deinstallationsziel angegeben ist, muss ich dann alles manuell löschen?

Installieren Sie jedes Programm in einer dedizierten Verzeichnisstruktur und verwenden Sie Stow oder XStow , um alle Programme in einer gemeinsamen Hierarchie anzuzeigen . Stow erstellt symbolische Links vom programmspezifischen Verzeichnis zu einem gemeinsamen Baum.

Wählen Sie beispielsweise ein Verzeichnis der obersten Ebene aus /usr/local/stow. Installieren Sie jedes Programm unter /usr/local/stow/PROGRAM_NAME. Sorgen Sie beispielsweise dafür, dass die ausführbaren Dateien in /usr/local/stow/PROGRAM_NAME/bin, die Manpages in /usr/local/stow/man/man1usw. installiert werden . Wenn das Programm autoconf verwendet, führen Sie es aus ./configure --prefix /usr/local/stow/PROGRAM_NAME. Nachdem Sie gelaufen sind make install, führen Sie aus stow:

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

Und jetzt haben Sie symbolische Links wie diese:

/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

Sie können leicht verfolgen, welche Programme Sie installiert haben, indem Sie den Inhalt des stowVerzeichnisses auflisten , und Sie wissen immer, zu welchem ​​Programm eine Datei gehört, da es eine symbolische Verknüpfung zu einem Speicherort unter dem Verzeichnis dieses Programms ist. Deinstallieren Sie ein Programm, indem Sie es ausführen und stow -D PROGRAM_NAMEanschließend das Programmverzeichnis löschen. Sie können ein Programm vorübergehend nicht verfügbar machen, indem Sie es stow -D PROGRAM_NAMEausführen (ausführen stow PROGRAM_NAME, um es wieder verfügbar zu machen).

Wenn Sie in der Lage sein möchten, schnell zwischen verschiedenen Versionen desselben Programms zu wechseln, verwenden Sie /usr/local/stow/PROGRAM_NAME-VERSIONals Programmverzeichnis. Um ein Upgrade von Version 3 auf Version 4 durchzuführen, installieren Sie Version 4 und führen Sie es aus stow -D PROGRAM_NAME-3; stow PROGRAM_NAME-4.

Ältere Versionen von Stow gehen nicht weit über die in dieser Antwort beschriebenen Grundlagen hinaus. Neuere Versionen sowie XStow (das in letzter Zeit nicht mehr gepflegt wurde) verfügen über erweiterte Funktionen, z. B. die Möglichkeit, bestimmte Dateien zu ignorieren, vorhandene Symlinks außerhalb des Stow-Verzeichnisses (z. B. man -> share/man) besser zu verarbeiten und Konflikte automatisch zu behandeln (wenn zwei vorhanden sind) Programme liefern die gleiche Datei) usw.

Wenn Sie keinen Root-Zugriff haben oder nicht verwenden möchten, können Sie ein Verzeichnis unter Ihrem Home-Verzeichnis auswählen, z ~/software/stow. In diesem Fall ergänzen Sie ~/software/binIhre PATH. Wenn manManpages nicht automatisch gefunden werden, fügen Sie sie ~/software/manzu Ihren hinzu MANPATH. Fügen Sie ~/software/infozu Ihrem INFOPATH, ~/software/lib/pythonzu Ihrem PYTHONPATHusw. hinzu, sofern zutreffend.

Sie können checkinstall verwenden , um ein Paket zu erstellen (RPM-, Deb- oder Slackware-kompatible Pakete). Auf diese Weise können Sie mit Ihrem Distributionspaket-Manager die Anwendung hinzufügen / entfernen (aber nicht aktualisieren).

Sie verwenden checkinstallanstelle des make installBefehls (mit dem -D-Parameter für Deb; -R ist RPM und -S ist Slackware):

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

checkinstall erstellt und installiert das Paket standardmäßig, oder Sie können das Paket nur ohne Installation erstellen lassen.

checkinstall ist in den meisten Distributions-Repositories verfügbar.

Zum größten Teil war dies der Grund für Pakete, Ports und andere Arten von Managern, um zu verhindern, dass so etwas passiert.

Ich würde sagen, dass manuelles Löschen die einzige Möglichkeit für eine manuelle Installation ist, es sei denn, jemand anderes hat eine bessere Antwort auf diesen Punkt, den ich möglicherweise nicht kenne.

Eine weitere Alternative sind die Linux From Scratch-Hinweise :

Mehr Kontrolle und Paketverwaltung mit Paketbenutzern

3 Paketbenutzer
3.1 Einführung

Die Grundidee dieses Schemas ist leicht zu erklären. Jedes Paket gehört einem bestimmten "Paketbenutzer". Wenn Sie ein Paket installieren, erstellen und installieren Sie das Paket als dieser Paketbenutzer, wodurch alle installierten Dateien dem Paketbenutzer gehören. Infolgedessen können alle üblichen Paketverwaltungsaufgaben bequem durch die Verwendung von Standardbefehlszeilendienstprogrammen ausgeführt werden. Ein einfacher Befehl ls -l <file>sagt Ihnen beispielsweise, zu welchem ​​Paket es <file>gehört, und ein find -user ...Befehl ermöglicht es Ihnen, alle zu einem bestimmten Paket gehörenden Dateien zu bearbeiten, z. B. zu löschen, um das Paket zu deinstallieren.

Die Paketverwaltung ist jedoch nicht alles, wofür Paketbenutzer gut sind. Da Paketbenutzer nicht über Root-Rechte verfügen, ist die Installation eines Pakets in ihren Möglichkeiten begrenzt. Eine Sache, die ein Paketbenutzer nicht tun darf, ist beispielsweise, Dateien von einem anderen Paketbenutzer zu überschreiben. Konflikte zwischen verschiedenen Paketen, die eine Binär-, Bibliotheks- oder Headerdatei mit demselben Namen installieren möchten, sind häufiger als Sie vielleicht denken. Bei Paketbenutzern besteht nie das Risiko, dass bei der Installation von Paket B Dateien aus Paket A unbemerkt gelöscht werden. Bei jedem Versuch, dies während der Installation von Paket B zu tun, wird der Fehler "Berechtigung verweigert" oder "Vorgang nicht zulässig" angezeigt, sodass Sie die Möglichkeit haben, die entsprechenden Schritte auszuführen. Eine andere Sache, die Paketbenutzer nicht tun dürfen, ist die Installation von setuid-Root-Binärdateien. Die Entscheidung, ein binäres setuid-Stammverzeichnis zu erstellen, möchte ein umsichtiger Administrator nicht dem Ersteller eines Softwarepakets überlassen.

In der Regel haben Paketbenutzerkonten kein gültiges Kennwort, sodass nur Root-Benutzer Zugriff su auf ein Paket haben. Dadurch wird sichergestellt, dass Paketbenutzer keinen zusätzlichen Zugang zum System erhalten und die Sicherheit untergraben. Sie können jedoch trotzdem Kennwörter festlegen, damit ein Co-Administrator, der bestimmte Softwarepakete installieren und warten kann, dies tun kann, ohne Zugriff auf das eigentliche Root-Konto. Dieser Co-Administrator kann beispielsweise zusätzliche Bibliotheken installieren, löschen und ändern, die für seine Arbeitsgruppe erforderlich sein könnten. Er ist jedoch nicht in der Lage, Bibliotheken wie libc zu entfernen oder zu ändern, die ihm nicht gehören.

Nach diesem ersten groben Vorschlag fand ich eine weiterentwickelte Variante:

crablfs - Benutzerbasiertes Paketverwaltungssystem

Dies crablfsist das neueste Exemplar der Paketverwaltung, das eindeutige UIDs und GIDs für die Paketverwaltung verwendet. Auf SourceForge wird es jedoch in ulfs erneut weiterentwickelt:

uLFS: Ihr verwaltbares und wiederverwendbares Linux von Grund auf neu

Für kausale Benutzer installierter Pakete halte ich die LFS-Lösung "package users" für eine leichte, weniger invasive und elegante Lösung. Kurz gesagt, Sie installieren Pakete in /usr/localoder /home/user/localund verfolgen Dateien unter Verwendung eindeutiger UIDs und GIDs für jedes Paket, speichern jedoch alle Dateien an den herkömmlichen Orten, in gemeinsamen Verzeichnissen /usr/local/bin, /usr/local/libwie es in allen gängigen Linux-Distributionen der Fall ist ... Verschließen von Dateien und unerwünschtes Überschreiben oder Löschen von Dateien Dies wird durch einen von Matthias S. Benkmann in more_control_and_pkg_man.txt erläuterten, sauberen Linux-Trick vermieden, der nur eine normale Manipulation der Datei- und Verzeichnisberechtigungen erfordert, z. B. die Sticky-Bit-Berechtigung für Verzeichnisse, um unerwünschtes Überschreiben von Dateien zu vermeiden:

3.3 Gruppen

Jeder Paketbenutzer gehört mindestens 2 Gruppen an. Eine dieser Gruppen ist die Gruppe "install", zu der alle Paketbenutzer (und nur Paketbenutzer) gehören. Alle Verzeichnisse, in denen Pakete Dateien installieren dürfen, gehören zur Installationsgruppe. Dies schließt Verzeichnisse wie / bin und / usr / bin ein, schließt jedoch Verzeichnisse wie / root oder / aus. Die Verzeichnisse der Installationsgruppe sind immer für Gruppen beschreibbar. Dies würde für die Aspekte der Paketverwaltung ausreichen, würde jedoch ohne weitere Vorbereitung keine zusätzliche Sicherheit oder Kontrolle bieten, da jedes Paket die Dateien eines anderen Pakets ersetzen könnte (die Änderung wäre in der Ausgabe von sichtbar)ls -lobwohl). Aus diesem Grund erhalten alle Installationsverzeichnisse das Attribut sticky. Auf diese Weise können Benutzer neue Dateien erstellen und ihre eigenen Dateien im Verzeichnis löschen oder ändern. Dateien anderer Benutzer können jedoch nicht geändert oder entfernt werden. Wenn im Rest dieses Hinweises der Begriff "Installationsverzeichnis" verwendet wird, bezieht er sich auf ein Verzeichnis, das zur Gruppeninstallation gehört, gruppenbeschreibbar und dauerhaft ist. IOW, <dir>in ein Installationsverzeichnis zu verwandeln, das Sie tun würden

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

Für mich sieht es nach einer einfachen und cleveren Lösung aus! Ich habe dieses Schema in meinem LFS-Build verwendet und es ist eine funktionierende Lösung ...

1. Sie können ein leeres RPM als Erinnerung erstellen.
2. Sie können überprüfen, ob die Software ordnungsgemäß in ein RPM eingebunden ist.
3. Sie können eine Kopie der tarDateien aus der Installation hinterlassen, um /usr/src/non-rpmssich daran zu erinnern (das mache ich normalerweise).