Logfiles und Konfiguration bei `make uninstall' entfernen?

[Meillo]

Hoi,

ich bin (mal wieder) auf der Suche nach Erfahrungswissen.

Ich bin der Meinung, dass `make uninstall' all das wieder entfernen soll was `make install' installiert hat. Soweit ist das klar, doch was ist mit Dateien die durch die Programmbenutzung generiert wurden und mit welchen die der Benutzer verändert hat?

Also, wie gehe ich mit /var/log/foo/* um? Komplett entfernen oder dort belassen?

Und was ist mit /etc/foo/*? Entfernen, belassen, nur entfernen falls unverändert (= evtl. hoher Aufwand)?

Oder ist da noch ein anderes Makefile Target üblich um dies abzudecken?


Mich interessiert insbesondere wie das bei anderer Software gehandhabt wird.

[hikaru]

Mir wäre es neu, dass make für das Entfernen von Erzeugnissen des fertigen Programms zuständig wäre. Vielleicht willst du ja angelegte Konfigurationen auch behalten, weil du eine neuere Version deines Programms mit den gleichen Einstellungen laufen lassen willst und dazu erstmal die alte Version mit make uninstall entfernst. make uninstall ist nicht für das Entfernen von mit dem Programm erzeugten Dateien zuständig. Ob es dafür ein alternatives Target gibt weiß ich nicht.

[Meillo]

Mir wäre es neu, dass make für das Entfernen von Erzeugnissen des fertigen Programms zuständig wäre.

Mit ``Ergzeugnissen'' sind in erster Linie Logfiles gemeint.

Vielleicht willst du ja angelegte Konfigurationen auch behalten, weil du eine neuere Version deines Programms mit den gleichen Einstellungen laufen lassen willst und dazu erstmal die alte Version mit make uninstall entfernst.

Sicher. Aber vielleicht will ich diese Dateien ebenfalls entfernen. Bei APT ist das ja schön getrennt: `remove' entfernt alle installierten Dateien, `purge' zusätzlich die Konfiguration.

make uninstall ist nicht für das Entfernen von mit dem Programm erzeugten Dateien zuständig. Ob es dafür ein alternatives Target gibt weiß ich nicht.

Man kann argumentieren, dass sich so ``Müll'' im Filesystem ansammelt. Falls es kein weiteres Target dafür gibt.

[hikaru]

Mit ``Ergzeugnissen'' sind in erster Linie Logfiles gemeint.

Ich meine damit alles was durch die Anwendung des Programms, nicht dessen Installation entsteht. Wenn das Programm während seiner normalen Arbeit Logs anlegt, dann sollten diese auch nach einem make uninstall bestehen bleiben um im Fall einer Neuinstallation die Kontinuität zu bewahren.
Wie mit Logs zu verfahren ist die während der Installation selbst entstehen bin ich mir nicht sicher.

Man kann argumentieren, dass sich so ``Müll'' im Filesystem ansammelt. Falls es kein weiteres Target dafür gibt.

Ja. Ein zusätzliches Target halte ich in jedem Fall für sinnvoller, als alles in eines zu zwängen.
Ich war eine Zeit lang C-Programmierer. Mit den Makefiles hatte ich kaum zu tun, aber ich kann mich nicht an ein uninstall erinnern, das mehr entfernt hat als make und make install erzeugt haben.

Unabhängig davon ist es vermutlich sinnvoll, deinen Nutzern die Verwendung von checkinstall zu empfehlen.

[peschmae]

make uninstall ist nicht für das Entfernen von mit dem Programm erzeugten Dateien zuständig. Ob es dafür ein alternatives Target gibt weiß ich nicht.

Man kann argumentieren, dass sich so ``Müll'' im Filesystem ansammelt. Falls es kein weiteres Target dafür gibt.

Falls der bevorzugte Verbreitungs-/Installationsweg des Programmes via Quellcode und make ist, wäre ein solches Target sicher eine sehr nette Sache.

Allerdings habe ich sowas noch nie gesehen, selbst wenn ich es gesucht habe. Deshalb denke ich, die meisten User würden das sowieso übersehen. Vergebene Liebesmüh quasi.

Viel wichtiger ist meiner Meinung nach, dass man es den Paketierern möglichst einfach macht, qualitatitv hochwertige Pakete für die diversen Distributionen zu erstellen... (z.B. indem man möglichst viele Standardkomponenten im Buildsystem einsetzt, also das grässliche autoconf/make...)

MfG Peschmä

[Meillo]

make uninstall ist nicht für das Entfernen von mit dem Programm erzeugten Dateien zuständig. Ob es dafür ein alternatives Target gibt weiß ich nicht.

Man kann argumentieren, dass sich so ``Müll'' im Filesystem ansammelt. Falls es kein weiteres Target dafür gibt.

Falls der bevorzugte Verbreitungs-/Installationsweg des Programmes via Quellcode und make ist, wäre ein solches Target sicher eine sehr nette Sache.

Allerdings habe ich sowas noch nie gesehen,

Also selbst einen Namen erfinden ... :-/

selbst wenn ich es gesucht habe. Deshalb denke ich, die meisten User würden das sowieso übersehen. Vergebene Liebesmüh quasi.

Ach, so sehe ich das nicht. Der Aufwand ist dafür nicht so groß und wenn nur einer oder zwei, oder ich selbst, es mal verwenden können hilft's ja schon.

Viel wichtiger ist meiner Meinung nach, dass man es den Paketierern möglichst einfach macht, qualitatitv hochwertige Pakete für die diversen Distributionen zu erstellen... (z.B. indem man möglichst viele Standardkomponenten im Buildsystem einsetzt, also das grässliche autoconf/make...)

... oder das Buildsystem sehr einfach aufgebaut ist.

[peschmae]

... oder das Buildsystem sehr einfach aufgebaut ist.

Das ist natürlich auch immer eine gute Option. Insbesondere wenn es so einfach ist, dass man es verstehen kann ohne komplett wahnsinnig zu werden.

Wobei das dann manchmal die Sache auch etwas schwerer macht (z.B. wenn das Install-Target keinen Prefix unterstützt und so).

MfG Peschmä

[Meillo]

... oder das Buildsystem sehr einfach aufgebaut ist.

Das ist natürlich auch immer eine gute Option. Insbesondere wenn es so einfach ist, dass man es verstehen kann ohne komplett wahnsinnig zu werden.

... man könnte denken, das wäre ironisch gemeint, doch leider ist das die Realität.

Wobei das dann manchmal die Sache auch etwas schwerer macht (z.B. wenn das Install-Target keinen Prefix unterstützt und so).

Wenn es das nicht tut, dann ist das schlecht, egal welcher Art der Buildsystem ist. Das betrifft aber einen der Standardfälle.

Was Sonderwünsche angeht, so baue ich die am liebsten von Hand mit dem Editor in ein kleines Makefile ein. Dann weiß ich wenigstens was ich getan habe und dass es auch so funktioniert wie ich es will.