Programme/Libs entfernen, updaten ohne Paketmanager
-
ProgChild schrieb:
Wenn man aber mal Pakete am Packetmanager vorbei installieren muss, weil es das Packet gerade nicht für deinen Packetmanager gibt, dann ist das schon recht praktikabel.
Sehe ich anders.
Sowas ist ein verwaltungstechnischer Albtraum; und eigene Pakete für den jeweiligen Paketmanager kann man sich meistens recht leicht erstellen; insofern ist das keine so tolle Idee.Btw, wenn ich während der Installation oder während der endlosen Laufzeit des find-Durchlaufes selbst irgendwelche neuen Dateien erstelle, dann versagt Dein Vorschlag schon und löscht mir ebendiese wieder, wenn ich eigentlich nur das Programm deinstallieren wollte...
Kurzum: Lustige Idee, aber nicht praxistauglich.
-
Wie merkt eigentlich der Paketmanager, welche Dateien installiert wurden?
Bei nem Source basierten Packetmanager könnte man die install.sh manipulieren, um die Dateien zu erfahern, aber wie läuft das denn z.B. bei Portage? Dass der nicht nach neuen Dateien sucht, ist mir klaar.
-
das paket sagt, was es wo installiert.
-
@nman Wenn Shade Of Mine recht hat, dann muss man erst mal rausfinden, welche Dateien installiert werden bevor man ein Packet erstellen kann. Und das muss man dann wohl mit find oder mit manipulation der install.sh machen, oder gibts noch nen anderen Weg? Alle Makefiles nach dem install Target absuchen finde ich etwas umständlich, wäre aber auch ne möglichkeit.
Noch ein Hinweis zu der Methode mit find: Man sollte sich die Dateilist noch mal anschauen, damit da nix gelöscht wird, was wichtig ist. Man kann auch mit grep z.B. /tmp, /home und /var herrausfiltern lassen.
-
Bei gentoo werden Pakete z.B. zuerst nach /var/tmp/portage/paketname/image/ installiert. Den Inhalt davon merkt sich portage, bevor er nach / verschoben wird.
-
SG1 schrieb:
Bei gentoo werden Pakete z.B. zuerst nach /var/tmp/portage/paketname/image/ installiert. Den Inhalt davon merkt sich portage, bevor er nach / verschoben wird.
Wie macht portage das denn eigentlich, wenn ein Packet, wie GAIM den Pfad zu seinen Dateien als prefix/share/gaim als absoluten Pfad includiert. Dann kann man ja configure --prefix=/var/tmp/portage/paketname/image schon mal nicht benutzen. Aber wie dann? Vielleicht ein chroot nach /var/tmp/portage/paketname/image, oder so?
-
./configure --prefix=/usr
make
make install DESTDIR=/var/tmp/portage/gaim/imageBraucht zwar spezielle Unterstuetzung im Makefile, aber die gibt's bei erstaunlich vielen Paketen. Und bei den Ausnahmen wird halt das Makefile gepatched.
-
Danke!
-
SG1 schrieb:
Braucht zwar spezielle Unterstuetzung im Makefile, aber die gibt's bei erstaunlich vielen Paketen.
Naja, so erstaunlich ist das gar nicht; alles was auf autotools aufsetzt, stellt DESTDIR zur Verfügung.
Noch ein Hinweis zu der Methode mit find
Dadurch wirds auch nicht brauchbar, sorry.
-
nman schrieb:
Dadurch wirds auch nicht brauchbar, sorry.
Du brauchst dich nicht dafür entschuldigen. Wenn du es nicht benutzen möchtest, dann ist das deine Sache. Mir hat das aber schon einigen Ärger erspart. Mir sind schon so einige Packete über den weg gelaufen, die definitiv kein DESTDIR hatten. Und für sowas dann mehrere Makefiles patchen? Schön, dass dir an deinem Paketmanager so viel liegt, aber ich hatte bis vor zwei Wochen nicht mal einen und bin recht gut zurecht gekommen.
-
Wenn ich mit einem DESTDIR-artigen Hack schneller bin und das ganze eleganter lösen kann als mit einem Hack der ein "find /" beinhaltet, dann mache ich das natürlich so.
Wenn Du sowas verwendest, ist das ja auch Deine Sache, aber weise nichtsahnende Neulinge bitte darauf hin, dass das ein verdammt dreckiger Hack ist.
-
nman schrieb:
Wenn ich mit einem DESTDIR-artigen Hack schneller bin und das ganze eleganter lösen kann als mit einem Hack der ein "find /" beinhaltet, dann mache ich das natürlich so.
Wenn Du sowas verwendest, ist das ja auch Deine Sache, aber weise nichtsahnende Neulinge bitte darauf hin, dass das ein verdammt dreckiger Hack ist.
Weist du sie auch darauf hin, dass sie dann die Makefiles zu dir schicken, damit du sie anpasst?
Dass du Makefiles patchen kannst, davon gehe ich aus, "aber weise nichtsahnende Neulinge bitte darauf hin", dass so ein Makefile hack auch mal negative folgen haben kann, bzw. das Packet dann nicht klappt, wenn mans nicht richtig macht.
-
ProgChild schrieb:
Dass du Makefiles patchen kannst, davon gehe ich aus, "aber weise nichtsahnende Neulinge bitte darauf hin", dass so ein Makefile hack auch mal negative folgen haben kann, bzw. das Packet dann nicht klappt, wenn mans nicht richtig macht.
Tja, aus Fehlern lernt man eben.
Und wenn man beim Versuch etwas richtig zu machen scheitert, ist das meines Erachtens besser, als wenn man es "erfolgreich" falsch macht.