Optimale Verwaltung von "Sonderpaketen"?

Hallo,

ich möchte gerne Pakete von Drittanbietern optimal handhaben/verwalten.
Für .rpm-Pakete aus anderen Quellen mache ich das indem ich diese in den Ordner "RPM-Pakete" in meinem /Home speichere.
Diesen Ordner habe ich als Repo in Yast eingebunden und installiere/deinstalliere sauber mittels Yast/Zypper. Perfekte Lösung!

Wie aber gehe ich bei .tar.gz.-Dateien optimal vor?
Existiert hierfür auch ein "Trick" oder Tool?

Edit (02.02.15):
Habe den Titel verändert, da es hier um die Verwaltung von "Sonderpaketen" geht und nicht um .tar.gz.-Dateien.
Das wird im Verlauf des threads noch klar werden!

Selbst RPMs bauen wäre wohl die sauberste Variante
(oder schaun, ob diese nicht vielleicht doch irgendwo schon exitieren )

@admine:
Das ist mir auch klar
Gibt es sonst keine Möglichkeit?

Da tar.gz an sich ja keine Pakete sind, gibts auch nicht wirklich eine Verwaltung dafür.

@towo:
Naja .. es ist doch auch ein Paket, oder? Ein verpacktes, archiviertes "Paket". Verpackung bedeutet ja zumindest bei der Post ein Paket zu erstellen...
Allerdings kann alles moegliche gepackt worden sein: Programme, Textdateien, Videos....
Also druecke ich mich mal anders aus:
Wie verwalte ich .bin-Dateien optimal?
Ihr wisst schon was ich meine: Nicht als .deb oder .rpm oder .sonstwas kompilierte Pakete, sondern solche wie man sie tw. auf diversen Homepages fuer Linux/Allgemein und Distributionsunabhaengig zum Download angeboten bekommt.

Genauso wie .zip Dateien, .rar Dateien, .txt Dateien, .bmp Dateien oder was auch immer für Dateien die man so erstellt oder runterlädt...indem man sie in eine den eigenen Bedürfnissen entsprechende Dateisystemstruktur/Verzeichnissturktur einsortiert zum Beispiel
tar.gz ist nur ein Archivdateiformat wie zip, lzh, tar.bz2, rar, arj, pak, arc oder was auch immer und sagt rein gar nichts über dessen komprimierten Inhalt aus (sofern man nicht pseudointelligenterweise irgendeine Datei einfach so benannt hat die noch nichtmal das erwartete Archivformat innehat)....
Ergo: Konqeuror, Dolphin, MidnightCommander, Krusader, Fileroller oder was auch immer man für einen Dateimanager bevorzugt ist dafür das Tool der Wahl.

Wenn der Entwickler bzw. Hersteller bestimmte Verzeichnisse für die Programme und Bibliotheken vorgibt, dann dokumentiert er das auch, und dann mußt Du das Archiv entsprechend auspacken. Ansonsten gehört alles, was am Paketmanager vorbei installiert wird, gemäß Dateisystem-Hierarchie nach /usr/local.

@josef-wien:
Alles nach /usr/local ... verstehe.
Wenn man alle am Paketmanager vorbei installierten Programme nach /usr/local installiert hat man eine gute Übersicht.
Werden denn die Bibliotheken, Manuals.. etc.. auch verlässlich in die jeweiligen Unterordner /usr/local/lib, usr/local/man.. etc installiert?

josef-wien schrieb:

Wenn der Entwickler bzw. Hersteller bestimmte Verzeichnisse für die Programme und Bibliotheken vorgibt, dann dokumentiert er das auch, und dann mußt Du das Archiv entsprechend auspacken.

Zum Vergrößern anklicken....

Das bedeutet also das es auch Programme gibt die nicht in /usr/local installiert werden?
Genau das ist mein Problem! Irgendwann wird das Ganze nämlich unübersichtlich und ich weiß nicht mehr wo ich überall welche Programme und deren zugehörige Bibliotheken etc.. installiert habe!.. In /usr/local befinden sich einige, manche wurden in andere Verzeichnisse installiert..
Das ist der Grund für meine Frage!
Ich dachte da gibt es auch einen Weg wie man hier eine Übersicht behalten kann um auch sauber wieder zu deinstallieren.
Nützlich fände ich z.B. ein Tool welches eine Paketverwaltung und Datenbank für am Paketmanager vorbei installierte Programme anbietet!

Wie sieht es eigentlich aus mit /opt?

http://wiki.ubuntuusers.de/Verzeichnisstruktur schrieb:

/opt
Von: optional; ist für die manuelle Installation von Programmen gedacht, die ihre eigenen Bibliotheken mitbringen und nicht zur Distribution gehören;

Zum Vergrößern anklicken....

Klingt für mich irgendwie fast gleich!

linux-freund schrieb:

Für .rpm-Pakete aus anderen Quellen mache ich das indem ich diese in den Ordner "RPM-Pakete" in meinem /Home speichere.
Wie aber gehe ich bei .tar.gz.-Dateien optimal vor?
Existiert hierfür auch ein "Trick" oder Tool?

Zum Vergrößern anklicken....

Ja, gibt es. Das nennt sich "checkinstall". Man verwendet das (nach der Installation), indem man im Kompilierungsprozeß statt "make install" "checkinstall" eingibt. Anstatt die kompilierten Dateien dann ins System zu prügeln, wo man sie nicht ohne weiteres wieder herausbekommt, baut einem das ein praktisches rpm.
Leider klappt das nicht immer. Aber immer öfter.

Eigentlich müßten die anderen, die hier schon - anders - geantwortet haben, das auch kennen.

linux-freund schrieb:

http://wiki.ubuntuusers.de/Verzeichnisstruktur

Zum Vergrößern anklicken....

Aktuelle Version 2.3: http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/opt.html
Entwurf zur Version 3.0: http://www.linuxbase.org/betaspecs/fhs/fhs.html#optAddonApplicationSoftwarePackages

Danke schonmal für die Antworten!

Ich mache mich gerade etwas schlauer zur Thematik und bin auf eine interessante Anleitung von Linux From Scratch hierzu gestoßen:
http://mengelke.zapto.org/linux/LinuxFromScratch/chapter06/pkgmgt.html
Hier werden verschiedene Wege zur Lösung der Problematik dargestellt.
Den Punkt "Paketverwaltung mit symbolischen Links" finde ich interessant.
Hier werden verschiedene Tools (Stow, Epkg, Graft und Depot) benannt die die Installation und Deinstallation in /usr/local mittels symbolischer Links übersichtlicher organisieren helfen. Weitere Tools mit ähnlicher Funktionalität die ich beim Stöbern gefunden habe wären: spill, toast , relink

Ich habe mir außerdem überlegt das btrfs+snapper auch genutzt werden können um Paketinstallationen sauber wieder rückgängig zu machen.
Snapper zeigt ja die jeweiligen Veränderungen in einem Snapshot an.. Ich kann also vor der Installation eines Paketes einen Snapshot erstellen. Allerdings sehe ich das Problem das ich beim Rückspielen auf den Snapshot vor Paket1 ungewollt auch alle nachfolgend installierten Pakete (Paket2, Paket3..) rückgängig mache. Aber ich kann mir zumindest ansehen welche Änderungen eine Paketinstallation alle durchgeführt hat, was schonmal ein Anhaltspunkt fürs weitere Vorgehen ist.

linux-freund schrieb:

Danke schonmal für die Antworten!

Ich mache mich gerade etwas schlauer zur Thematik und bin auf eine interessante Anleitung von Linux From Scratch hierzu gestoßen:
http://mengelke.zapto.org/linux/LinuxFromScratch/chapter06/pkgmgt.html
Hier werden verschiedene Wege zur Lösung der Problematik dargestellt.
Den Punkt "Paketverwaltung mit symbolischen Links" finde ich interessant.
Hier werden verschiedene Tools (Stow, Epkg, Graft und Depot) benannt die die Installation und Deinstallation in /usr/local mittels symbolischer Links übersichtlicher organisieren helfen. Weitere Tools mit ähnlicher Funktionalität die ich beim Stöbern gefunden habe wären: spill, toast , relink

Zum Vergrößern anklicken....

Sorry, Du bist auf dem Holzweg: rpm ist das Paketsystem von OpenSuSE und einigen anderen Distributionen.
.tar.gz ist dagegen ein gepacktes Format, in dem üblicherweise der Source-Code zur Verfügung gestellt wird. Dieser Source-Code wird dann für ganz unterschiedliche Systeme (32bit, 64bit, Linux, Solaris, FreeBSD, Windows, usw.) kompiliert. .tar.gz ist also nicht als Paketsystem gedacht. Du solltest es auch nicht so behandeln. Wenn Du eine Paktetverwaltung unter OpenSuSE nutzen willst, mußt Du rpm verwenden. Wenn Du ein .tar.gz hast, mußt Du es entpacken ("tar -xzvf mysource.tar.gz") und den Source-Code darin für Dein spezielles System kompilieren (das von "./configure" ermittelt wird). Wenn das klappen sollte, hast Du schließlich fertige Programmdateien in Deinem Unterverzeichnis. Die kannst Du dann unkontrolliert ins System kopieren lassen, üblicherweise von "make install", oder ein rpm daraus bauen lassen mit "checkinstall". Dieses rpm kann dann von den Paketverwaltungsprogrammen wie zypper oder YaST verarbeitet werden. Das geht mit .tar.gz nicht, weil es ein Format für einen ganz anderen Zweck ist.

Die Angaben auf "Linux from Scratch" beziehen sich auf minimale Distributionen, die ganz auf große Paketverwaltungssysteme wie rpm verzichten wollen. Dort werden Notlösungen vorgestellt, um die Installation der Programmdateien trotzdem einigermaßen unter Kontrolle zu halten. Wenn man rpm zur Verfügung hat, braucht man solche Notlösungen nicht.

@abgdf:
Ich habe den Titel des threads unglücklich gewählt! (Edit 02.02.2015 - Und daher heute geändert!)
Das man RPM-Dateien am besten über die SUSE-eigenen Paketmanager verwaltet ist mir schon klar.

Die Pakete von denen ich spreche sind:
1. direkt am System vorbei mit einer speziellen Setuproutine vom Programmanbieter installierte Pakete (z.B. kommerzielle Software für Mac, Windows und Linux)
2. Programme in Skriptsprache.

http://wiki.ubuntuusers.de/Programme_kompilieren/Alternativen schrieb:

Solche Programme müssen nicht kompiliert werden und die Skripte übernehmen lediglich die Aufgabe, die Dateien an den richtigen Ort zu kopieren, um das Programm systemweit verfügbar zu machen.

Zum Vergrößern anklicken....

3. Programme für Linux, die mit vorkompilierten, ausführbaren Dateien (Binaries) angeboten werden. Diese Programme müssen ebenfalls nicht kompiliert werden.
4. Was es sonst noch an Varianten gibt.

Für diese "Sonderpakete" suche ich nach einer möglichst einfach zu handhabenden Lösung der Verwaltung.

Wie ich beim Recherchieren herausfinden konnte scheint das von abgdf bereits erwähnte checkinstall hierfür die beste existierende Möglichkeit zu sein.
Dieses Tool scheint auch die Möglichkeit zu bieten, die oben von mir genannten Sonderpakete zu installieren:
Programme in Skriptsprache und vorkompilierte Programme:

http://wiki.ubuntuusers.de/Programme_kompilieren/Alternativen schrieb:

Für eine komfortable Installation solcher Skripte sollte man den Vorgang mit checkinstall abfangen. Zwei Beispiele anhand eines Shell- und eines Python-Skriptes:
Statt:

Code:

./install.sh
python setup.py install

Also:

Code:

sudo checkinstall ./install.sh
sudo checkinstall python setup.py install

Zum Vergrößern anklicken....

Eine andere Variante ist das Tool "Stow":

http://linuxwiki.de/Stow schrieb:

Bei Stow installiert man die Programme nicht direkt dorthin, wo sie eigentlich hingehören, sondern ins Unterverzeichnis "stow". Wenn man z.B. nmap mit stow nach /usr/local installieren möchte, installiert man es nach /usr/local/stow/nmap-x.xx. Dann führt man stow aus, welches die Symlinks nach /usr/local anlegt.
Wenn man nmap jetzt wieder loswerden möchte, geht das ganz einfach: Man löscht zuerst die Symlinks mit Hilfe von Stow und dann das nmap-verzeichniss in /usr/local/stow

Zum Vergrößern anklicken....

Interessanterweise wird Stow seit openSUSE13.2 in den offiziellen Paketquellen angeboten und Checkinstall nicht (mehr).
In den openSUSE13.1 Paketquellen sieht es genau andersrum aus: Checkinstall:ja, Stow:nein !
Warum ist das so? Vertraut man Stow neuerdings mehr als Checkinstall?

Für die in meiner obigen Liste erwähnten "direkt am System vorbei mit einer speziellen Setuproutine vom Programmanbieter installierten Pakete" könnte checkinstall auch funktionieren wenn ein Installskript Verwendung findet denke ich.
Ich denke daher das Checkinstall die meisten Optionen bietet und am Besten für meine Zwecke geeignet ist. Oder habe ich was falsch verstanden?

Ich habe gerade mal checkinstall ausprobiert mit dem Paket PDFStudio_v9_2_1_linux64.sh von hier: http://www.qoppa.com/pdfstudio/demo/download/
Das ist ein "direkt am System vorbei mit einer speziellen Setuproutine vom Programmanbieter installiertes Paket (z.B. kommerzielle Software für Mac, Windows und Linux)".

Ich habe das Paket in mein /home-Verzeichnis geladen und dann im betreffenden Ordner als Root
ausgeführt

Ich wollte ein RPM-Paket erstellen und dieses dann mit Yast installieren.
Leider hat es nicht funktioniert. Es konnte kein RPM-Paket erstellt werden.
Statt dessen wurde ein Paket: backup-013120152037-pre-PDFStudio_v9_2_1_linux64-v9_2_1_linux64.tgz erstellt!
Was genau ist das jetzt für ein Paket? Was kann ich damit machen?

Was kann ich damit machen?

Zum Vergrößern anklicken....

Nichts!
checkinstall geht nur bei Sourcecode, nicht bei binarys oder scripten.

@towo:
Da hab´ ich anderes gelesen:

http://www.linuxfocus.org/Deutsch/December2004/article360.shtml schrieb:

CheckInstall macht jedoch nicht zwingend von make install Gebrauch, sondern arbeitet auch problemlos mit anderen Installationsbefehlen zusammen. Lautet das Installationsskript beispielsweise setup.sh sieht der Befehlssatz so aus:

Code:

./configure && make && checkinstall setup.sh

Zum Vergrößern anklicken....

Außerdem im bereits vorab von mir geposteten Link http://wiki.ubuntuusers.de/Programme_kompilieren/Alternativen:
Ab "Installationsskripte":

wiki.ubuntuusers.de schrieb:

Programme in Skriptsprachen wie Python, Perl, Ruby usw. bieten oftmals Installationsskripte an. Solche Programme müssen nicht kompiliert werden und die Skripte übernehmen lediglich die Aufgabe, die Dateien an den richtigen Ort zu kopieren, um das Programm systemweit verfügbar zu machen. So etwas ist auch für vorkompilierte Programme zutreffend.

Zum Vergrößern anklicken....

wiki.ubuntuusers.de schrieb:

Für eine komfortable Installation solcher Skripte sollte man den Vorgang mit checkinstall abfangen. Zwei Beispiele anhand eines Shell- und eines Python-Skriptes:
Statt:

Code:

./install.sh
python setup.py install

Also:

Code:

sudo checkinstall ./install.sh
sudo checkinstall python setup.py install

Zum Vergrößern anklicken....

linux-freund schrieb:

http://wiki.ubuntuusers.de/Programme_kompilieren/Alternativen

Zum Vergrößern anklicken....

Der letzte Absatz "Vorkompilierte Programme" hat im wesentlichen nichts mit dem Rest des Dokuments zu tun. *buntu verwendet übrigens rpm nicht.

Du solltest Dich mit dem Programm rpmbuild beschäftigen.

josef-wien schrieb:

Der letzte Absatz "Vorkompilierte Programme" hat im wesentlichen nichts mit dem Rest des Dokuments zu tun.

Zum Vergrößern anklicken....

Daher war ich mir auch unsicher ob man checkinstall auch auf vorkomplilierte Programme anwenden kann.

josef-wien schrieb:

*buntu verwendet übrigens rpm nicht.

Zum Vergrößern anklicken....

Ach was? Ist mir auch klar!
Aber punkto Anleitungen zu Pakete aus Sourcen kompilieren, checkinstall.. etc macht das wohl kaum einen Unterschied!
Das Ubuntu-Wiki eignet sich hervorragend als Nachschlagwerk zu sämtlichen Linux-Themen ob RPM oder nicht.

josef-wien schrieb:

Du solltest Dich mit dem Programm rpmbuild beschäftigen.

Zum Vergrößern anklicken....

Das habe ich bereits vor einiger Zeit getan.. ist schon etwas komplexer.
Ich hatte mir erhofft auch einfachere Wege als RPM-Bau zu finden.

Daß checkinstall auch anderes als Source-Code verarbeitet, wußte ich auch nicht. Wieder was gelernt.

Sehr viele Module oder Programme in Skriptsprachen sind ja auch über YaST als rpms verfügbar. Die übrigen installieren sich meist nach "/usr/lib/python/site-packages" für Python und in Unterverzeichnisse von "/usr/lib/perl5" für Perl. Da sie meist nicht so groß sind, kann man es verschmerzen, wenn man sie da nicht mehr vollständig herausbekommen sollte.
Shellskripte sind meist Einzelskripte, die man sich nach "/usr/local/bin" kopiert. Eigentlich auch kein Problem.
Bleiben bestimmte ClosedSource-Programme, die man nur als Binärdateien bekommt. Unter Linux wohl sehr die Ausnahme.
Insgesamt besteht für einen Paketmanager für solche besonderen Fälle wohl kein so großes Bedürfnis. Wer auch diese unbedingt verwalten will, müßte sich wohl damit vertraut machen, wie man genau rpms baut. Ich bin da bisher (seltsamerweise) drumherumgekommen.

Schon nach ein paar Monaten werden sowieso die Rufe laut, daß man gefälligst seine Platte insgesamt für die neueste Distribution zu plätten haben.

@abgdf:
Danke für die nützlichen Hinweise punkto Python, Perl und Bash-Skripte!

abgdf schrieb:

Bleiben bestimmte ClosedSource-Programme, die man nur als Binärdateien bekommt. Unter Linux wohl sehr die Ausnahme.

Zum Vergrößern anklicken....

Und auch Open-Source Binärdateien wie z.B. das weiter oben von mir erwähnte PDFStudio von Qoppa.
Es sind Ausnahmen, da geb´ ich Dir Recht. Ich scheue mich bislang davor solche Programme zu testen, weil ich mir damit das System zumüllen, vermurksen und schlimmstenfalls zerschießen könnte! Außerdem möchte ich nach dem Testen solche Programme dann auch wieder sauber deinstallieren können.