Upgrades: Geänderte Programmdateien überschreiben lassen

[heisenberg]

Hi,

ich habe gerade ein Upgrade von Buster auf Bullseye durchgeführt(im Zuge eines Proxmox Mail Gateway Upgrades). Dabei bin ich auf die Problematik gestossen, die ich gerne jeweils vorab abfangen möchte.

Ich habe eine Datei aus den Proxmox-Paketen geändert: Ich habe den Hinweis, dass für die Installation keine Software-Subscription aktiv ist, aus dem Code(proxmoxlib.js) rausgepatched.

Zur Info: Proxmox VE ist Open Source. Auf der ethischen Ebene ist das jetzt natürlich eine wichtige Entscheidung, über die ich mir natürlich auch Gedanken gemacht habe. Ich finde die Proxmox und die Open Source Software, die diese Firma produziert sehr wertvoll und möchte das auch honorieren und auch etwas zurück geben. Ich tue das in dem Maße, in dem das in meiner Umgebung möglich ist. Ich bitte um Verständnis, dass ich auf dieses Thema hier nicht weiter eingehen werde.

Also: Ich habe eine Programmdatei geändert. Jetzt gab es ein Update. Wahrscheinlich wurde ich während des Upgrades gefragt, ob ich die von mir geänderte Datei überschreiben möchte und habe wahrscheinlich nicht so genau gelesen und habe wie immer "nein" gewählt. Folge war: Das Webinterface hat danach nicht funktioniert, weil die geänderte Datei eine JS-Datei - jetzt alte Version - für das Webinterface war.

Meine Frage ist, ob ich diese Datei irgendwie im Paketmanagement so deklarieren kann oder auf einem anderen Weg dafür sorgen kann, dass diese Datei bei einem Paketupgrade auf jeden Fall überschrieben wird?

Danke & Grüße,
h.

[hikaru]

Du könntest ein eigenes Debianpaket erstellen, das die veränderte Datei an einem alternativen, unkritischen Ort ablegt.
Im postinst-Script sicherst du die Originaldatei und schiebst die alternative Datei an ihre Stelle. Im prerm-/postrm-Script stellst du das Original wieder her. So kannst du über die (De)Installation des Pakets bestimmen, welche Variante der Datei vorliegt, ohne dass apt zunächst über doppelte Dateien meckert.
Zusätzlich bestimmst du in der control-Datei dieses Pakets einen Konflikt mit dem Proxmox-Paket das die Originaldatei ausliefert, sofern dessen Version höher ist, als die Aktuelle.

Auf diese Weise triggert ein Proxmox-Upgrade die Deinstallation deines Pakets und stellt somit die Originaldatei wieder her.
Der Nachteil ist natürlich, dass du dich nun zusätzlich zum Patch der Originaldatei auch noch um das Debianpaket kümmern musst. Zumindest musst du nach jedem Proxmox-Upgrade die Konflikt-Version anpassen.

[uname]

Ich habe eine Datei aus den Proxmox-Paketen geändert: Ich habe den Hinweis, dass für die Installation keine Software-Subscription aktiv ist, aus dem Code(proxmoxlib.js) rausgepatched. ... Ich bitte um Verständnis, dass ich auf dieses Thema hier nicht weiter eingehen werde.

Ich finde es eher schlimm, dass die Software nicht gleich einen Schalter hierfür vorsieht. Vielleicht sollte mal jemand einen Issue erstellen.
Wem hilft die Information wirklich? Ist es relevant? Bzw. darf man es gegenüber seinen Kunden verheimlichen bei einer OpenSource-Software?

Aber ich möchte auf was anderes hinaus:
Proxmox VE unterliegt AGPLv3.
Somit bist du verpflichtet deinen Anwendern den Quellcode inkl. deiner Anpassungen bereitzustellen.
Ich denke du kannst auf die Originalquellen verweisen. Aber auch die Anpassung hättest du seinerzeit bereitstellen müssen.
Das hast du bestimmt getan.

Zum eigentlichen Problem:

Meine Frage ist, ob ich diese Datei irgendwie im Paketmanagement so deklarieren kann oder auf einem anderen Weg dafür sorgen kann, dass diese Datei bei einem Paketupgrade auf jeden Fall überschrieben wird?

Ich hatte immer gedacht, dass Anpassungen bei Aktualisierungen einfach übergebügelt werden. Ist das nicht so?
Gibt es dafür nicht im Paketmanagement von Debian irgendeine Option?
Vielleicht kannst du auch mal "debsums" oder sowas drüber laufen lassen.
Da solltne ja Abweichungen zum Orginal-Paket direkt auffallen.

[heisenberg]

... eigenes Debianpaket erstellen ...

Danke. Das ist ein möglicher Ansatz. Ich denke mal darüber nach, ob man das nicht besser machen kann.

[heisenberg]

Ich finde es eher schlimm, dass die Software nicht gleich einen Schalter hierfür vorsieht. Vielleicht sollte mal jemand einen Issue erstellen. Wem hilft die Information wirklich? Ist es relevant? Bzw. darf man es gegenüber seinen Kunden verheimlichen bei einer OpenSource-Software?

Die Information hilft imho ausschließlich dem Hersteller der Software(Proxmox) dabei, die eigenen Entwickler zu bezahlen. Ich muss schon sagen, da diese Software imho wirklich gut ist, dass man hier so viel für umme bekommt, bin ich bereit diese Winzigkeit an Unsauberkeit bzw. des Eigeninteresses klaglos hinzunehmen. Die Tatsache, dass die Software kostenfrei ist, bzw. man die Wahl hat, ob und wieviel man bezahlen möchte(über die Auswahl der Subscriptions. Bei "mir" läuft natürlich auch die eine oder andere Subscription; aber eben nicht für alle Server) und dass viele Menschen, die es sich nicht leisten können dadurch freien Zugriff auf die Software haben, das finde ich schon einen großen Dienst an der Gesellschaft - also fast so viel wie komplett freie Software.

Nachtrag: Ich finde es auch schon gut, dass die Firma nach und nach weitere OSS Projekte aufzieht. Bei dieser Firma finde ich es besonders einfach, diese zu unterstützen bzw. eine Rechtfertigung für die Unterstützung zu haben. Was die alles kostenfrei zur Verfügung stellt, finde ich sehr gut. (Natürlich nutzen die auch selbst viel vom OSS-Pool und gerade das macht diese Projekte für mich sehr sympathisch).

Ich denke du kannst auf die Originalquellen verweisen. Aber auch die Anpassung hättest du seinerzeit bereitstellen müssen. Das hast du bestimmt getan.

Natürlich! Was denkst Du nur von mir?

Zum eigentlichen Problem:

...Vielleicht kannst du auch mal "debsums" oder sowas drüber laufen lassen...

Ja. Schaue ich mal, ob das hilft.

[JTH]

Wahrscheinlich wurde ich während des Upgrades gefragt, ob ich die von mir geänderte Datei überschreiben möchte und habe wahrscheinlich nicht so genau gelesen und habe wie immer "nein" gewählt.

Das kommt drauf an. Wo liegt die erwähnte Datei denn? Eine Frage, ob die Änderungen überschreiben möchtest, bekommst du normalerweise nur für Konfigurationsdateien unter /etc.

Alle anderen Dateien, die bei einem Upgrade evtl. lokale Änderungen haben, werden ohne Nachfrage stillschweigend überschrieben. Das meint alle Dateien, die du mit

Code: Alles auswählen

dpkg -L PAKET

gelistet bekommst, abzüglich derer unter /etc. Deshalb wird an anderer Stelle ja gerne davon abgeraten, etwa Dateien, Skripte in /usr o.ä. zu modifizieren – die Änderungen gehen bei Upgrade womöglich ungewollt verloren.

Dateien, die ein Paket evtl. in seinen Maintainerskripten preinst oder postinst anlegt (die sind bei dpkg -L nicht aufgeführt), sind von dem Verhalten ausgenommen. Was mit denen bei einem Upgrade passiert, ist von der Gunst des Paketmaintainers abhängig.

Folge war: Das Webinterface hat danach nicht funktioniert, weil die geänderte Datei eine JS-Datei - jetzt alte Version - für das Webinterface war.

Ohne das ich Proxmox kenne – so wie du es beschrieben hast und wenn das ein sauberes Upgrade über apt+dpkg war, würde ich die Fehlerursache eher nicht in deinen vorherigen Modifikationen suchen. (Vorausgesetzt, du hattest mit denen nichts kaputt gemacht )

Meine Frage ist, ob ich diese Datei irgendwie im Paketmanagement so deklarieren kann oder auf einem anderen Weg dafür sorgen kann, dass diese Datei bei einem Paketupgrade auf jeden Fall überschrieben wird?

Das ist nicht notwendig, das ist das normale Verhalten, /etc ausgenommen.

[heisenberg]

@JTH: Danke.

Ich habe jetzt das Paket mal testweise per apt install --reinstall überschrieben und meine Änderungen sind wie gewünscht weg.

Problem war wohl mein Script(sed), dass in der neuen Version die Änderung so durchführt, dass es nicht mehr funktioniert.

[JTH]

Problem war wohl mein Script(sed), dass in der neuen Version die Änderung so durchführt, dass es nicht mehr funktioniert.

Das klingt doch sehr wahrscheinlich.

Vielleicht wäre ein sauberes Diff/ein Patch die bessere Lösung dafür? patch meckert dann, wenn die Änderung nicht mehr sauber wiederholt werden kann. Ist aber, als Plus, in der Lage, Verschiebungen um ein paar Zeilen zu tollerieren.

[novalix]

Für solche Fälle könnte

Code: Alles auswählen

man dpkg-divert

eine Lektüre wert sein.

[JTH]

Für solche Fälle könnte man dpkg-divert eine Lektüre wert sein.

Ich glaube, ihr habt zum Teil die Frage nicht richtig gelesen. heisenberg wollte doch gerade nicht, dass seine Modifikationen beim Upgrade erhalten bleiben

[novalix]

Als ich meinen Post abgesetzt habe, war das akute Problem bereits gelöst und das Problemfeld beleuchtet. Zu letzterem wollte ich den Hinweis auf ein vorhandenes Werkzeug im Paketierungskoffer geben.
Es handelt sich um eine Anmerkung zum Problemfeld. Ich hätte mich klarer ausdrücken sollen.

[JTH]

Zu letzterem wollte ich den Hinweis auf ein vorhandenes Werkzeug im Paketierungskoffer geben.

dpkg-divert ist ja auch ein hilfreiches Helferlein Zur Verwendung im Zusammenspiel mit debhelper in einem Debian-Paket ist zusätzlich config-package-dev ganz praktisch.

[heisenberg]

@novalix:

Danke für Deine Mühe. dpkg-divert ist mir bereits bekannt.