Eigene, private Debian-Backports verwalten: Mit git-buildpackage oder was anderem?

[Ralph Aichinger]

Ich möchte (in einer Gruppe von Leuten, d.h. nicht nur alleine) einen
privaten, internen Backport einer Debian-Package verwalten. Letztendlich
geht es im Moment mal nur darum eine einzelne Zeile im Debian/control-File
zu ändern, das kann natürlich mehr werden.

Gemäß dieser Anleitung hier:

https://www.ocf.berkeley.edu/docs/staff/procedures/backporting-packages/

war das einschließlich Anleitung durchlesen eine Sache von einer halben
Stunde. Aaaber:

Ich will das irgendwie in ein lokales git-Repository aufnehmen. Ist in dem Fall
die Toolsuite "git-buildpackage" das Werkzeug der Wahl? Leider sind die
diversen Workflows mit git-buildpackage in erster Linie so dokumentiert,
dass unterstellt wird, man würde unverpackte Upstream-Software
debianisieren wollen, weniger das Backporten z.B. eines offiziellen
Trixie-Packages nach Bookworm.

Von git-buildpackage mit seinen vielen Features fühl ich mich
einstweilen regelrecht erschlagen, verglichen mit der eigentlichen
Aufgabe (eine Zeile ändern, Package neu übersetzen) ist das deutlich
komplexer.

Bevor ich mich darin einarbeite möchte ich mich mal umhören, ob die
Zeitinvestition darin eine sinnvolle ist, oder ob es andere Tools gibt,
die diesen Usecase (lokale Packages mit minimalen Änderungen zum
Upstream oder lokale Backports) besser abdecken, und wie
git-buildpackage überhaupt eingeschätzt wird.

/ralph

[Marc Haber]

Post by Ralph Aichinger
Ich will das irgendwie in ein lokales git-Repository aufnehmen. Ist in dem Fall
die Toolsuite "git-buildpackage" das Werkzeug der Wahl? Leider sind die
diversen Workflows mit git-buildpackage in erster Linie so dokumentiert,
dass unterstellt wird, man würde unverpackte Upstream-Software
debianisieren wollen, weniger das Backporten z.B. eines offiziellen
Trixie-Packages nach Bookworm.

Wenn das Paket auf salsa ist:
- git clone
- ggf eigenen remote aufsetzen
- git checkout (die version aus trixie)
- git checkout -b my-bookworm-backport
- eine geeignete Versionsnummer im Changelog eingeben¹
- notwendige Änderungen
- gbp buildpackage (die wahl der passenden Optionen ist eine Übung)

¹ das ist eine Wissenschaft, sie muss größer als bookworm und kleiner
als trixie sein, und abhängig davon ob Du sie durch einen "offizielen"
Backport überschreiben möchtest kleiner oder größer als die
bpo-Versionsnummer. Meine Bookworm-Backports bekommen ~0~zg120+1 als
Suffix.

Ich werfe die Pakete dann mit reprepro in ein aptables Archiv.

Wenn eine neue Version in trixie ist, kannst Du deinen backport-Branch
auf die neue Version rebasen.

Beim Changelog, das immer konflikted, hilft:

|[merge "dpkg-mergechangelogs"]
|name = debian/changelog merge driver
|driver = dpkg-mergechangelogs -m %O %A %B %A
|# commit .git/info/attributes: debian/changelog merge=dpkg-mergechangelogs

Die Kommentarzeile sagt Dir was Du im Repository machen musst damit es
wirkt.

Grüße
Marc

[Ralph Aichinger]

Post by Marc Haber
- git clone
- ggf eigenen remote aufsetzen
- git checkout (die version aus trixie)
- git checkout -b my-bookworm-backport
- eine geeignete Versionsnummer im Changelog eingeben¹
- notwendige Änderungen
- gbp buildpackage (die wahl der passenden Optionen ist eine Übung)

Danke, ich werd mir das in einem ruhigen Momen ansehen.

Post by Marc Haber
¹ das ist eine Wissenschaft, sie muss größer als bookworm und kleiner
als trixie sein, und abhängig davon ob Du sie durch einen "offizielen"
Backport überschreiben möchtest kleiner oder größer als die
bpo-Versionsnummer. Meine Bookworm-Backports bekommen ~0~zg120+1 als
Suffix.

Ja, das hab ich schon mit einem Kollegen besprochen, wir wollen, dass
das backport-Paket spätestens beim Upgrade auf trixie automatisch
verschwindet.

Ich nehme an "zg" steht für "Zugschluss"? Ich möchte auch sowas
reinbekommen, daran bin ich aber noch gescheitert (bei mir war dan
irgendwas mit ~bpo drin, vom einem Backport-Flag von gbp oder so.
Das muß ich mir noch ansehen.

Post by Marc Haber
Ich werfe die Pakete dann mit reprepro in ein aptables Archiv.

Danke, schau ich mir an.

Post by Marc Haber
Wenn eine neue Version in trixie ist, kannst Du deinen backport-Branch
auf die neue Version rebasen.
|[merge "dpkg-mergechangelogs"]
|name = debian/changelog merge driver
|driver = dpkg-mergechangelogs -m %O %A %B %A
|# commit .git/info/attributes: debian/changelog merge=dpkg-mergechangelogs
Die Kommentarzeile sagt Dir was Du im Repository machen musst damit es
wirkt.

Danke!

/ralph

Post by Marc Haber
Grüße
Marc

[Marc Haber]

Post by Ralph Aichinger
Ich nehme an "zg" steht für "Zugschluss"?

Genau.

Post by Ralph Aichinger
Ich möchte auch sowas
reinbekommen, daran bin ich aber noch gescheitert (bei mir war dan
irgendwas mit ~bpo drin, vom einem Backport-Flag von gbp oder so.
Das muß ich mir noch ansehen.

bpo ist die markierung für backports.org. So hießen die "offiziellen"
Backports früher.

Grüße
Marc

[gregor herrmann]

Post by Marc Haber
|[merge "dpkg-mergechangelogs"]
|name = debian/changelog merge driver
|driver = dpkg-mergechangelogs -m %O %A %B %A
|# commit .git/info/attributes: debian/changelog merge=dpkg-mergechangelogs
Die Kommentarzeile sagt Dir was Du im Repository machen musst damit es
wirkt.

ich hab das mit den attributes global geloest:

in ~/.gitconfig:
[core]
attributesfile = ~/.gitattributes

in ~/.gitattributes:
debian/changelog merge=dpkg-mergechangelogs


gregor

[Marc Haber]

Post by gregor herrmann
[core]
attributesfile = ~/.gitattributes
debian/changelog merge=dpkg-mergechangelogs

Kann man dann noch lokale attributesfiles verwenden oder überschreibt
das die attributes aus Repositories dann global?

Grüße
Marc

[gregor herrmann]

Post by Marc Haber

Post by gregor herrmann
[core]
attributesfile = ~/.gitattributes
debian/changelog merge=dpkg-mergechangelogs

Kann man dann noch lokale attributesfiles verwenden oder überschreibt
das die attributes aus Repositories dann global?

hab jetzt ein bisschen gesucht - ich hab in einzelnen repos noch
..gittattributes files, die auf jeden fall honoriert werden, halt mit
anderen inhalten. was passieren wuerde, wenn global wie lokal die
gleichen dinge gesetzt werden, kann ich jetzt nicht sagen; aber bei
| debian/changelog merge=dpkg-mergechangelogs
scheint mir das fuer mich recht unproblematisch.

gregor

[Marc Haber]

Post by gregor herrmann

Post by Marc Haber

Post by gregor herrmann
[core]
attributesfile = ~/.gitattributes
debian/changelog merge=dpkg-mergechangelogs

Kann man dann noch lokale attributesfiles verwenden oder überschreibt
das die attributes aus Repositories dann global?

hab jetzt ein bisschen gesucht - ich hab in einzelnen repos noch
..gittattributes files, die auf jeden fall honoriert werden, halt mit
anderen inhalten. was passieren wuerde, wenn global wie lokal die
gleichen dinge gesetzt werden, kann ich jetzt nicht sagen; aber bei
| debian/changelog merge=dpkg-mergechangelogs
scheint mir das fuer mich recht unproblematisch.

Ich hab das endlich mal ausprobiert. Der Defaultpath zum globalen
Attributesfiles ist $XDG_CONFIG_HOME/git/attributes, also bei mir
/home/mh/.config/git/attributes, dann braucht man den Zirkus im
.gitconfig nicht. Die lokaleren attributes haben Vorrang, man kann
also einzelne Attributes aus ~/.config/git/attributes noch im
repository via .gitattributes im gleichen directory oder
repositoryweit mit dem File in .git überschreiben.
~/.config/git/attributes wird aber trotzdem gelesen, wenn es keine
Konflikte gibt bleiben die Settings aus dem File im Repository
erhalten.

Das ist also ohne böse Überraschungen direkt einsetzbar.

Sorry dass das so lange gedauert hat bis ich mal dazu gekommen bin.

Grüße
Marc

[gregor herrmann]

Post by Marc Haber

Post by gregor herrmann
hab jetzt ein bisschen gesucht - ich hab in einzelnen repos noch
..gittattributes files, die auf jeden fall honoriert werden, halt mit
anderen inhalten. was passieren wuerde, wenn global wie lokal die
gleichen dinge gesetzt werden, kann ich jetzt nicht sagen; aber bei
| debian/changelog merge=dpkg-mergechangelogs
scheint mir das fuer mich recht unproblematisch.

Die lokaleren attributes haben Vorrang, man kann
also einzelne Attributes aus ~/.config/git/attributes noch im
repository via .gitattributes im gleichen directory oder
repositoryweit mit dem File in .git überschreiben.
~/.config/git/attributes wird aber trotzdem gelesen, wenn es keine
Konflikte gibt bleiben die Settings aus dem File im Repository
erhalten.

sehr schoen, danke fuers ausprobieren und berichten!

gregor