tuxnix Das Array backup=() ist funktionell dafür da zu bestimmen, für welche Dateien der Mechanismus ausgelöst wird. Das Array sollte aber, bei der Entscheidung ob eine pacnew Datei nötig ist oder nicht, gar keine Rolle spielen.
Wenn ich dich nicht falsch verstehe:
Das backup-Feld ist das einzige Kriterium weshalb überhaupt *pacnew entstehen können für Dateien, die in beiden zu vergleichenden Paketen vorkommen. Ohne Einträge dort werden ansonsten alle in beiden Paketetversionen enthaltenen Dateien durch die der höheren Version überschrieben.
Der Mechanismus über die 3 Hash-Werte funktioniert IMHO richtig und ist äußerst wichtig. Keiner will z.B. seine /etc/shadow jedesmal mit einer "leeren" Version aus dem filesystem Paket ersetzt bekommen.
Zum speziellen Fall mit tpm2-tss:
- mir ist dieses Paket und dessen Konfig schnurzegal, ich nutze es aktiv nicht und auch kein TPM.
- Ich kenne dessen Funktionalität (auch als Abhängigkeit für etliche auch für mich wichtige Pakete) nicht. V.a. bin ich mir in keinster Weise sicher, ob und was der User überhaupt in diesen /etc/tpm2-tss/fapi-profiles/* Dateien - die nun im backup-Array sind - verändern können sollte oder müßte.
Ich kann direkt halt wenig zu sagen und habe eigentlich auch kein Interesse in diesem speziellen Fall das auseinander zu klamüstern...
tuxnix Was hältst du von einem Bugreport?
Klingt das logisch was ich mir hier überlegt habe?
IMHO beziehst du in deiner Überlegung den 3. Hash-Wert nicht richtig mit ein. Es ist halt einer dieser "raren" Ausnahmefälle von denen das Wiki spricht. Einfach eine ungünstige Konstellation (Ausnahme) für die der funktionierende Algorithmus keine Behandlung kennt (kennen kann?) und dann wenigstens das einzig richtige macht (also pacnew und Warnung, d.h. der Admin muß sich drum kümmern - was wir ja hier auch machen im Thread).
Ich kann nur logs nochmal zitieren aus dem .org-Thread:
dimich wrote:
It was unexpected that there is three-way difference in the directory that never being modified.
So the cause is that files included into backup list and their contents changed in the same upgrade?
Yes very unfortunate coincidence.
Nur weil eben beide Umstände gleichzeitig in einem Update vorkommen, also geänderte Datei gegenüber einer vorhandenen und (//edit: erstmalige) Aufnahme dieser Datei in den Mechanismus(x,y,,z) des backup-Arrays, ist diese Ausnahmesituation entstanden.
Die Devs (//Edit: respektive der Paketmaintainer) hätten das beim Test merken können ("Oha, da paßt was nicht") und eben als Lösung z.B. eine Paket-News rausbringen können. So aber ist zumindest kein "Schaden" entstanden, nur mehr Aufwand für den Admin.
Oder aber den Weg:
- erstes neues Release mit geänderten Dateien (es wären also beide Original/Aktuell-Dateien mit der neuen Version überschrieben worden)
- ein zweites Release in dem diese Dateien dann erstmalig in das backup-Array aufgenommen wären. Dann würden anhand des 3-Hashes-Vergleich IMHO keine *.pacnew entstehen (sofern die aktuelle Datei nicht vom User verändert wurde).
Dieser zweite Ansatz (2 Releases) hätte aber IMHO beträchtliche Nachteile/Probleme:
- Es würden im 1.Release schon Dateien mit Inhalt aus dem neuen Paket überschrieben, die "eigentlich" schützenswert sind
- Wenn das 1. Release vom User "übersprungen" würde(kein Upgrade zwischen Veröffentlichung von -1 und -2), dann steht der User doch vor wieder "unserem" Problem..
//Edit:
Ein "dritter" bzw. anderer Ansatz für den 2. Weg:
- ein neues Release ( 4.1.3-2) mit eben den gleichen Dateien wie in 4.1.3-1, aber Änderung der backup-Array Einträge
- zweites Release/Upgrade 4.2.0-1 dann mit den neuen, geänderten json-Files (die dann schon alle im backup-Array vom Vorgänger mit drin sind).
Das wäre IMHO auch ein möglicher Weg gewesen, Fallstrick aber auch hier: Wenn der user das erste Release zeitlich überspringt steht er vorm gleichen Prob wie jetzt auch. //Edit Ende
Das wäre also ziemlich viel "Aufwand" für so ein - ich sags mal salopp - "Popelpaket"...
Also ich sehe da keinen Fehler in pacman für einen ansonsten seit Jahren (toi-toi-toi) wunderbar und erprobt funktionierenden Bestandteil(eben Behandlung von Konfig-Dateien).
Der einzig ("Hej, Bro!, voll") "korrekte" Weg wäre gewesen:
News:
- Das Update für tpm2-tss erfordert einen manuellen Eingriff
- Durch die erstmalige Aufnahme der folgenden Dateien in den Backup.Mechanismus für Konfigfiles entstehen bei einem Upgrade von 4.1.3-1 zu 4.2.0-1 (oder größer) einmalig *.pacnew Sicherungsdateien.
- Wenn eure Originaldateien dieses <Datum>(oder<Hash-Wert>) haben dann können diese durch die jeweiligen *.pacnew ersetzt werden.
- Ansonsten pflegt(merged) die neuen Änderungen in eure aktuelle Konfig ein. Achtung: das Format bzw. der Ihalt beider Versionen hat sich erheblich geändert!
Sowas in dieser Art halt... Mehr gibt's da IMHO nicht zu sagen zu (oder Zeit reinzustecken...) <g>
//Edit:
tuxnix Ich halte es für einen bug in pacman aufgrund einer verunglückten Logik.
...
tuxnix Ein "original=X, aktuell=X" bleibt immer ein "original=X, aktuell=X" !
IMHO "vergißt" du hier den 3. Hash-Wert bzw. interpretierst X falsch.
X = Original = Hash fürs Original, das ist aber ein eigener Hash für eben %BACKUP% Files. Nicht der sha-Dateihash aus dem alten Paket (mtree).
Y = Aktuell = Hash der Datei im Filesystem
Z = Neu = Hash der Datei aus den neuen Paket
Schau dir mal für dein Paket filesystem /var/lib/pacman/local/filesystem-<version> an.
In mtree sind die Hashes aller Files (notwendig für z.B. -Qkk)
In files sind unten dann aber im %BACKUP% Abschnitt die "speziellen" Hashes für die Files, die im backup-Array drin sind (das "X = Original")
Für tpm2-tss war es nun wirklich so:
X(Original) = NULL (kein hinterlegter Hash in files->Backup da bisher kein Eintrag in backup=())
Y(Aktuell) = 12345
Z(Hash Neu) = 67890
Da Y ungleich Z entsteht korrekt eine pacnew, da von beiden Kriterien:
- original=X, aktuell=Y, neu=Z
- original=NULL, aktuell=Y, neu=Z
die zweite greift.
Es ist nicht:
- original = aktuell(X=Y), neu=Z (also überschreiben ohne pacnew)
da ja X nicht existiert (in files->Backup! Das ist das wo X herkommt).
Zumindest für mich macht das Sinn...
//Edit Ende