Debian Pakete selbst kompilieren

[mcb]

Sorry,

ich habe ein par Pakete aus Sid und Testing selbst unter Bullseye kompiliert (nach dieser einfachen Anleitung https://wiki.debian.org/SimpleBackportCreation)

Sind die erstellten Pakete dann wirklich anders als die aus den Repros? Ich ändere ja keinen Quellcode.

Beispiel inxi -> macht es einen Unterschied ob ich die Version aus Testing nehme oder diese selbst kompiliere. Ersteres soll man nicht aus gutem Grund, soweit ist es klar (bzw. bei einem Programm ohne Abhängigkeiten könnt man es auf eigenes Risiko versuchen).

Nur was macht man mit Programmen die devlibs aus sid voraussetzen?

PS: inxi war der erste Versuch - klar es gibt einen Backport, aber zum testen...

[inne]

Wenn Du am Quellcode nichts änderst, sollte es doch das selbe Paket sein (Die Bauwerkzeuge tun da nicht so viel, was ich wüsste)? Heuer hat man auch reproduzierbare Binaries, aber dort verstehe ich nicht alles von (nur soviel das z.B. die Ausgabe von strings.1 die gleiche sein sollte).

Wenn auch Libs usw. aus Sid gebraucht werden würde ich stoppen, weil das ein ewiger Rattenschwanz wird, der einem irgendwann auf die Füsse fällt. So meine Erfahrung.
Aber dann tuts ein Downgrade (der schon installieten Libs usw) auf stable zu versuchen eigentlich, wenn man den hinbekommt. Oder testing ist dann schon im freeze
Oder einfach kein Paket bauen, sondern den Code so via Dreisatz kompilieren/installieren (Dann fällt die debian/control weg)? Mit Glück kann man auch Upstream noch gegen Libs aus stable bauen und nach ~/.local oder halt /usr/local installieren?

PS: Statt testing in der sources.list geht auch git und salsa und von dort das Paket holen, habe ich mir angewöhnt. Account kann man auch bekommen, wenn man dem Admin genehm ist (Ich habe keinen bekommen!) Dann sind vlt. auch eigene patches einfacher selbst zu pflegen usw.

[mcb]

Ja Danke - 'singemäß' habe ich es ja ähnlich verstanden

und mir ist leider nicht klar, wiso das selbst gebbaute Paket dann gesünder ist, als das Paket aus z.B. sid.

Den "Rattenschwanz" von devlibs wollte ich mir nicht geben (o.k. die sind nur zum kompillieren, oder?).

Mischen mit einer einstelligen Zahl Pakete konnte ich bisher immer managen. Ich gehe dabei aber wirklich vorsichtig vor.

Das selbstgebaute Cryptsetup habe ich bisher lieber nicht probiert:

Code: Alles auswählen

root@mb:~/build# ll cry*.deb
-rw-r--r-- 1 root root 237564 Sep  9 21:36 cryptsetup_2.4.0-1~bpo11+1_amd64.deb
-rw-r--r-- 1 root root 417536 Sep  9 21:36 cryptsetup-bin_2.4.0-1~bpo11+1_amd64.deb
-rw-r--r-- 1 root root 289912 Sep  9 21:36 cryptsetup-bin-dbgsym_2.4.0-1~bpo11+1_amd64.deb
-rw-r--r-- 1 root root  28440 Sep  9 21:36 cryptsetup-dbgsym_2.4.0-1~bpo11+1_amd64.deb
-rw-r--r-- 1 root root  72996 Sep  9 21:36 cryptsetup-initramfs_2.4.0-1~bpo11+1_all.deb
-rw-r--r-- 1 root root  54940 Sep  9 21:36 cryptsetup-run_2.4.0-1~bpo11+1_all.deb
root@mb:~/build# 

[inne]

und mir ist leider nicht klar, wiso das selbst gebbaute Paket dann gesünder ist, als das Paket aus z.B. sid.

Bei inxi kann ich es dir nicht sagen. Irgendwas wird dich doch darauf gebracht haben nicht die Version aus stable zu nehmen? Ich kenne inxi nicht und weiss auch nicht warum es davon einen Backport gibt. Das wäre dann wohl ein Grund.

Den "Rattenschwanz" von devlibs wollte ich mir nicht geben (o.k. die sind nur zum kompillieren, oder?).

Den Begiff devlibs habe ich hier nun so gelesen das Du damit Bauabänhanigkeiten meinst. Die werden dann auch zur Laufzeit benötigt, beim Bau verweist man doch auf diese. Oder was genau meinst du mit devlibs (bei Debian)?

// Ok, du meinst die Includes/Header also -dev Pakete usw., die braucht man soweit ich weiss nur zum Bau, müssen aber zur Version passen.

Mischen mit einer einstelligen Zahl Pakete konnte ich bisher immer managen. Ich gehe dabei aber wirklich vorsichtig vor.

Es kann nur dazu kommen das die Lib in stable in der Paketverwaltung mit der neuen aus Sid kollidiert (Wenn Du da Pakete baust). Im Extremfall.
Kann man bestimmt auch lösen (mit eigenen Paketversionsnummern (~local) usw.) ab mir wäre das dann zu viel, ob es dann mit apt-get dist-upgrade usw. alles noch tut. Und überhaupt noch Kompatibilität gegeben ist.

[hikaru]

inxi ist nur ein Perl-Script, das aus grundlegenderen Systemtools Informationen zusammenträgt. Beim Backport wird hier also nichts compiliert, sondern nur ein Paket geschnürt. Build-deps in Form zusätzlicher dev-Pakete gibt es daher in dem Sinne hier nicht.
Der Grund dafür, das überhaupt ein Backport existiert sind entweder neu Features oder Bugfixes. Im Zuge dessen, könnten sich Abhängigkeiten geändert haben, weil z.B. eine neue Funktion ein weiteres Systemtool benötigt. Aber eigentlich sind solche Script-Backports eher trivial.

Komplizierter wird es bei Backports von Paketen, die compilierte Binaries enthalten. Zu diesen Binaries brauchst du passende Build-deps und wenn die nicht von deinem Release erfüllt werden können, dann musst du zunächst die Build-deps backporten. Diese können ihrerseits wieder Build-deps haben. Daher kommt der Rattenschwanz. Wie weit du den verfolgen willst, musst du selbst abwägen. Manchmal ist es nach ein oder zwei Stufen getan und dann kann sich ein Backport lohnen, aber es kann auch schnell ausufern.

Ein Backport (egal ob ein offizieller oder ein selbstgebauter) ist deshalb "gesünder" als ein Sid-Paket, weil du beim Bau mitbekommst, wenn es Inkompatbilitäten zwischen deinem Release und dem Paket gibt. Diese wirst du bei einem erfolgreichen Backport zwangsläufig behandeln und hoffentlich dabei auch verstehen, ob es Grenzen dieser Behandlung gibt und, wenn ja, wo die liegen. Das Backport-Paket ist also gewissermaßen das "Zeugnis" dafür, dass inkompatibilitäten irgendwie behandelt wurden. Installierst du stattdessen blind das Sid-Paket, kann es dir unvermittelt um die Ohren fliegen.

Fiktives Beispiel:
Es gibt eine neue inxi-Version in Sid, die gegenüber Stable zwei neue Funktionen mitbringt, welche über die Schalter A und B angsteuert werden können. Funktion A interssiert dich, daher möchtest du das Paket backporten. Funktion A hat keine zusätzlichen Abhängigkeiten, also wäre der Backport trivial.
Funktion B hat aber eine unbehandelbare Abhängigkeit in Form eines neuen Systemtools das sich nicht (sinnvoll) backporten lässt. Ruft man inxi mit Schalter B auf, ohne dass das dafür nötige Systemtool installiert ist (oder weil die Stable-Version des Tools einen schweren Bug hat), dann frisst es deine Kinder und öffnet die Tore zur Hölle. Schalter B interessiert dich aber eigentlich gar nicht. Deshalb deaktivierst du den beim Backport und musst dich später nicht vor dessen Gefahren fürchten.
Hättest du stattdessen das Sid-Paket installiert, müsstet du bei jeder inxi-Nutzung (z.B. auch copy&paste aus dem Netz) daran denken, nicht versehentlich Schalter B zu legen.

Edit:
Ich würde empfehlen, Backports immer in einem separaten, sauberen System zu erstellen. Für triviale Fälle richt hier pbuilder. Die meisten anderen Fälle lassen sich in einem chroot erledigen. Kommt der Kernel mit in's Spiel, dann ist eine VM sinnvoll.
Sauber im Sinne von nicht durch frühere Builds kontaminiert sollte die Umgebung sein, weil sich sonst der Build unvorhersehbar verhalten kann, teils auch unerwartet unvorhersehbar. [1]


[1] viewtopic.php?f=25&t=181796

[inne]

und mir ist leider nicht klar, wiso das selbst gebbaute Paket dann gesünder ist, als das Paket aus z.B. sid.

Bei inxi kann ich es dir nicht sagen. Irgendwas wird dich doch darauf gebracht haben nicht die Version aus stable zu nehmen? Ich kenne inxi nicht und weiss auch nicht warum es davon einen Backport gibt. Das wäre dann wohl ein Grund.

Ok, du meintest den selbst gebauten Backport.

Wenn sich das Paket aus Sid installieren lässt kannst Du das auch nehmen. Das läuft wie ich finde aufs selbe raus. Wenn tut später beides nicht mehr, das Paket aus sid unter stable nicht mehr oder der Backport lässt sich nicht mehr bauen.
Hier sollten die Paketbetreuer die Abhängigkeiten richtig beachtet haben. Bei Perl sind es dann die Module oder bei inxi dann noch die Tools die aufgerufen werden.

Scheinbar, weder hier nicht mal Versionen definiert: https://git.unit193.net/cgit/users/unit ... an/control

[mcb]

inxi ist n....

Ein Backport (egal ob ein offizieller oder ein selbstgebauter) ist deshalb "gesünder" als ein Sid-Paket, weil du beim Bau mitbekommst, wenn es Inkompatbilitäten zwischen deinem Release und dem Paket gibt. Diese wirst du bei einem erfolgreichen Backport zwangsläufig behandeln und hoffentlich dabei auch verstehen, ob es Grenzen dieser Behandlung gibt und, wenn ja, wo die liegen. Das Backport-Paket ist also gewissermaßen das "Zeugnis" dafür, dass inkompatibilitäten irgendwie behandelt wurden. Installierst du stattdessen blind das Sid-Paket, kann es dir unvermittelt um die Ohren fliegen.

...........
Edit:
Ich würde empfehlen, Backports immer in einem separaten, sauberen System zu erstellen. Für triviale Fälle richt hier pbuilder. Die meisten anderen Fälle lassen sich in einem chroot erledigen. Kommt der Kernel mit in's Spiel, dann ist eine VM sinnvoll.
Sauber im Sinne von nicht durch frühere Builds kontaminiert sollte die Umgebung sein, weil sich sonst der Build unvorhersehbar verhalten kann, teils auch unerwartet unvorhersehbar. [1]


[1] viewtopic.php?f=25&t=181796

Ah ok - wenn der build mit Fehlern abbricht habe ich natürlich erstmal die Segel gestreckt - Virtualbox z.B. / das Paket aus sid lief zu der Zeit aber unter Bullseye (ev. mit kleinen Macken).

Falls eien devlib beim Bau fehlt erstelle ich einen Backport eben dieser - auch verstanden. Das hilft mir weiter.

Das "saubere System" zum bauen - starte ich dann jedesmal mit einem frischen Bullsey?

[mcb]

und mir ist leider nicht klar, wiso das selbst gebbaute Paket dann gesünder ist, als das Paket aus z.B. sid.

Bei inxi kann ich es dir nicht sagen. Irgendwas wird dich doch darauf gebracht haben nicht die Version aus stable zu nehmen? Ich kenne inxi nicht und weiss auch nicht warum es davon einen Backport gibt. Das wäre dann wohl ein Grund.

Ok, du meintest den selbst gebauten Backport.

Wenn sich das Paket aus Sid installieren lässt kannst Du das auch nehmen. Das läuft wie ich finde aufs selbe raus. Wenn tut später beides nicht mehr, das Paket aus sid unter stable nicht mehr oder der Backport lässt sich nicht mehr bauen.
Hier sollten die Paketbetreuer die Abhängigkeiten richtig beachtet haben. Bei Perl sind es dann die Module oder bei inxi dann noch die Tools die aufgerufen werden.

Scheinbar, weder hier nicht mal Versionen definiert: https://git.unit193.net/cgit/users/unit ... an/control

Ja ich Pro das war mein erstes Testprojekt, weil es eh einen Backport gibt (um zu üben).

[hikaru]

Das "saubere System" zum bauen - starte ich dann jedesmal mit einem frischen Bullsey?

Ja, z.B. indem du dir eine dedizierte Build-VM anlegst, nach deren Einrichtung einen Snapshot erstellst und die VM nach jedem Build auf diesen Snapshot zurücksetzt.

[mcb]

Das "saubere System" zum bauen - starte ich dann jedesmal mit einem frischen Bullsey?

Ja, z.B. indem du dir eine dedizierte Build-VM anlegst, nach deren Einrichtung einen Snapshot erstellst und die VM nach jedem Build auf diesen Snapshot zurücksetzt.

OK - auch verstanden