Paketupdate mit neuer Minor-Version, aber ohne Änderungen in Änderungshistorie

[emacs_fan]

Hallo und ein schönes neues Jahr,

regelmäßig update ich mein System über die Softwareverwaltung (Yast Software - Installationsquellen - alle in dieser Liste aktualisieren, falls neue Version verfügbar ist). In letzter Zeit ist mir aufgefallen, dass besonders häufig neue Minor-Versionen, z.B. von Cinelerra oder DVDStyler, installiert werden, bei denen aber laut Änderungshistorie des Pakets gar keine Änderung durchgeführt wurde (Reiter Änderungsprotokoll in Yast).

Bei den zwei o.g. Beispielen habe ich z.B. folgende Updates installiert:
Cinelerra: letzte Änderung in der Historie des Pakets/Programms vom 20.3.2013
2.2cv20120923-1.64 (installiert am 26.12.13)
2.2cv20120923-1.63 (25.12.13)
2.2cv20120923-1.61 (23.12.13)
2.2cv20120923-1.60 (18.12.13)
2.2cv20120923-1.58 (7.12.13)
usw.
DVDStyler: letzte Änderung in Historie vom 21.11.2013
2.6-1.13 (30.12.13)
2.6-1.12 (26.12.13)
2.6-1.11 (25.12.13).
usw.

Ich habe schon geschaut, ob zeitgleich ein Paket, welches Cinelerra benötigt "richtig" geupdated worden ist, konnte aber keinen Zusammenhang finden.

Habt ihr eine Idee, was sich an dem Paketen geändert hat und ob es sich überhaupt
lohnt die Version neu zu installieren? Oder anders gefragt: was sagt mir die Minor-Versionsnummer?

Danke & Gruß
emacs_fan

 

[Rain_Maker]

AW: Paketupdate mit neuer Minor-Version, aber ohne Änderungen in Änderungshistorie

Kurze Antwort:

Ganz so einfach ist es nicht.

Längere Antwort:

Zunächst mal hat sich da nicht die Versionsnummer sondern die "Releasenummer" geändert.

RPM-Pakete sind wie folgt nummeriert:

PAKETNAME-PAKETVERSION-ReleaseMajor.ReleaseMinor.ARCHITEKTUR.rpm

Also bedeutet die Änderung von

cinelerra-2.2cv20120923-1.63.i586.rpm

zu

cinelerra-2.2cv20120923-1.64.i586.rpm

eben _keine_ Änderung der Version, sondern des "Minor Releases".

Im Prinzip funktioniert das im OBS so.

- Paketierer checkt sein Paket FOO in Version 1.2.3 zum ersten mal ein, Ergebnis

FOO-1.2.3-1.1.ARCHITEKTUR.rpm

Und was nun passiert hängt davon ab, was sich am Paket geändert hat.

Fall A)

Paketierer baut Paket in neuerer Version, sagen wir in 1.2.4 und lässt es im OBS neu bauen, Ergebnis

FOO-1.2.4-1.1.ARCHITEKTUR.rpm

Fall B)

Paketierer ändert etwas am Paket _ohne_ die Version des Paketes selbst zu ändern, z.B. fügt er eine Änderung im .spec ein, Ergebnis

FOO-1.2.3-2.1.ARCHITEKTUR.rpm

Das Paket ist also immer noch in der selben Version vorhanden, das 2.1 deutet aber an "der Paketierer hat was am Paket geändert".

Fall C)

Irgendeine Abhängigkeit des Paketes wurde upgedatet, der OBS versucht das Paket neu zu bauen und vergleicht, ob sich gegenüber der vorigen Version etwas am Paket geändert hat. Findet er nichts, dann wird das Paket nicht veröffentlicht, findet er etwas, dann

FOO-1.2.3-1.2.ARCHITEKTUR.rpm

Haken an der Sache "findet er was" kann z.B. etwas sein, was gar nichts mit der Funktionalität des Paketes zu tun hat, der Klassiker ist z.B. der, daß beim Kompilieren das aktuelle Datum + aktuelle Zeit in irgendwelchen Binaries landen, die ändern sich logischerweise bei jedem "Neubau" und das erzeugt -in diesem Fall unnötige- Updates, weshalb man da in den .spec Dateien gerne ein wenig trickst um das zu vermeiden (führt aber hier zu weit).

Greetz,

RM

 

[emacs_fan]

AW: Paketupdate mit neuer Minor-Version, aber ohne Änderungen in Änderungshistorie

Hallo Rain_Maker,

vielen Dank für die ausführliche Erklärung - und natürlich auch die kurze.

Dann schließe ich daraus, dass die meisten Updates, die ich in der letzten Zeit runtergezogen habe primär verwaltungstechnische Änderungen beinhalten, aber keine wirkliche inhaltliche
Änderung. Da es mir zu kompliziert ist aber jedesmal die Releasenummer/Versionsnummer des Pakets auseinander zu nehmen werde ich wohl weiterhin updaten

Danke & Gruß
emacs_fan