Distribution mit eigenen Patches?

[Georg Schwarz]

Welche Distribution eignet sich, wenn man bei einigen Paketen eigene
Patches hinzufügen möchte, weil man mit mancher Design-Entscheidung
nicht zufireden ist oder manche Funktionalität vermisst?
Natürlich muss es zwangsläufig eine Distribution sein, die das eigene
Compilieren von zumindest ausgewählten Paketen ermöglicht.
Hab mir mal Arch-Linux angeschaut; da ginge es grundsätzlich, ebenso
wohl mit Manjaro, das ja auf Arch basiert. Vermutlich geht es mit jeder
Linux-Distribution grundsätzlich; aber einige eignen sich vielleicht
besser für solch einen Ansatz?

Hintergrund: ich habe eine bestimmte Funktionalität in KMail vermisst
und musste feststellen, dass die Entwickler sie explizit ausgebaut
hatten:
https://phabricator.kde.org/R94:1c55919a64491bd5598cf9d8616e77b037edbf87
Es gab schon einige Diskussionen dazu in den letzten Jahren, aber
offenbar ließen sie sich nicht zum Wiedereinbau bewegen.
Na ja, dafür ist es ja Open Source. Habe mir also das PKGBILD von
https://archlinux.org/packages/extra/x86_64/messagelib/ besorgt und
entsprechend nur die Sourcen holen lassen, manuell gepatcht und dann
gebaut (https://wiki.archlinux.org/title/Patching_packages erklärt es).
Klappte vorzüglich; die vermisste Funktionalität ist jetzt da.
Mein Testsystem war eine Manjaro-Installation.
Welche Distribution eignet sich am besten, wenn man sowas dauerhaft und
für einige Pakete machen möchte?
Welchen Mechanismus sollte man am besten zur Einbindung eines eigene
"Patch-Repositories" nutzen?
Hat jemand solch eine Konstruktion in Benutzung?

[Martin Vaeth]

Georg Schwarz <georg....@freenet.de> schrieb:

> Welche Distribution eignet sich, wenn man bei einigen Paketen eigene
> Patches hinzufügen möchte, weil man mit mancher Design-Entscheidung
> nicht zufireden ist oder manche Funktionalität vermisst?

Ganz klar: Gentoo.
Fast alle Design-Entscheidungen kannst Du dort mit USE-flags
kontrollieren. Und da es ohnehin Source-basiert ist, ist Patchen
auch kein Problem: Patch an die passende Stelle schieben - fertig.

[Martin Vaeth]

Martin Vaeth <mar...@mvath.de> wrote:
> Georg Schwarz <georg....@freenet.de> schrieb:
>> Welche Distribution eignet sich, wenn man bei einigen Paketen eigene
>> Patches hinzufügen möchte, weil man mit mancher Design-Entscheidung
>> nicht zufireden ist oder manche Funktionalität vermisst?
>
> Ganz klar: Gentoo.
> Fast alle Design-Entscheidungen kannst Du dort mit USE-flags
> kontrollieren.

Im konkreten Fall von kmail gibt es bei Gentoo nur die 5 USE-flags
debug handbook pch telemetry test.
Da dürfte vermutlich nicht das dabei sein, was Du willst.
Das ist allerdings nicht verwunderlich, wenn es eine
*Upstream*-Entscheidung war, da Gentoo nur in speziellen Fällen
Optionen zu denen von Upstream hinzufügt.

> Und da es ohnehin Source-basiert ist, ist Patchen
> auch kein Problem: Patch an die passende Stelle schieben - fertig.

Mit passender Stelle meine ich natürlich: einmalig;
nicht bei jedem Bauen.

Im konkreten Fall etwa in ein von Dir erstelltes Verzeichnis
/etc/portage/patches/kde-apps/kmail
(da wird der Patch dann bei jedem emerge irgendeiner kmail-Version
angewendet) oder
/etc/portage/patches/kde-apps/kmail-21.08.1
(dann wird er nur für die spezielle Version angewendet).
Wenn der Patch im ersten Fall für neuere Versionen nicht mehr geht,
liegt es natürlich in Deiner Verantwortung, ihn auf den neuesten
Stand zu bringen.

Es gibt auch noch zahlreiche andere Mechanismen, etwa solche,
mit denen du vor oder nach der Kompilation eigene Scripte ausführen
kannst, die dann denn Source patchen (etwa mit sed) - bei einfachen
Patches kannst Du Dir so manchmal die manuelle Anpassung des Patches
an eine neue Version sparen.

Oder Du schreibst Dir ein eigenes ebuild für kmail in Deinem
lokalen Overlay, wo Du dann auch andere Dinge wie Abhängigkeiten
ändern kannst, und ggf. bestimmen kannst, wenn/ob/wie automake
ausgeführt wird u.ä.

Wie gesagt: Mechanismen gibt es bei Gentoo viele, und welche man am
besten nutzt, hängt vom Einzelfall und in einfachen Fällen schlicht
vom Geschmack ab.

[Georg Schwarz]

Martin Vaeth <mar...@mvath.de> wrote:

> Mit passender Stelle meine ich natürlich: einmalig;
> nicht bei jedem Bauen.

natürlich.

>
> Im konkreten Fall etwa in ein von Dir erstelltes Verzeichnis
> /etc/portage/patches/kde-apps/kmail
> (da wird der Patch dann bei jedem emerge irgendeiner kmail-Version
> angewendet) oder

hört sich gut an. D.h. ein entsprechender Mechanismuss für lokale
Zusatzpatches ist bereits vorhanden und es mussen dafür keine
Build-Skripte angepasst werden?

> /etc/portage/patches/kde-apps/kmail-21.08.1
> (dann wird er nur für die spezielle Version angewendet).
> Wenn der Patch im ersten Fall für neuere Versionen nicht mehr geht,
> liegt es natürlich in Deiner Verantwortung, ihn auf den neuesten
> Stand zu bringen.

da führt natürlich kein Weg daran vorbei.

[Marc Haber]

georg....@freenet.de (Georg Schwarz) wrote:
>Welche Distribution eignet sich, wenn man bei einigen Paketen eigene
>Patches hinzufügen möchte, weil man mit mancher Design-Entscheidung
>nicht zufireden ist oder manche Funktionalität vermisst?
>Natürlich muss es zwangsläufig eine Distribution sein, die das eigene
>Compilieren von zumindest ausgewählten Paketen ermöglicht.

Ich kenne keine, die das nicht ermöglicht. Sowohl in der rpm als auch
in der dpkg-Welt gibt es sourcepakete die man laden, verändern und neu
bauen kann. Da muss man aber mit den Versionsnummern aufpassen, damit
man nicht bei Distributionsupdates das neue Paket mit
Defaulteinstellungen erhält, und man muss natürlich auch nachhalten,
welche sicherheitsrelevanten Änderungn in der Distribution erfolgt
sind.

Ich hab das früher regelmäßig gemacht, inzwischen ist's so eher nur
noch eine Hand voll pakete, und ich arbeite daran, das zu reduzieren.

>Welchen Mechanismus sollte man am besten zur Einbindung eines eigene
>"Patch-Repositories" nutzen?

In Debian wird relativ viel quilt verwendet, das ist aber nicht
überall der Fall.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Stefan Froehlich]

On Mon, 13 Sep 2021 08:28:07 Marc Haber wrote:
> georg....@freenet.de (Georg Schwarz) wrote:
> >Welche Distribution eignet sich, wenn man bei einigen Paketen
> >eigene Patches hinzufügen möchte, weil man mit mancher
> >Design-Entscheidung nicht zufireden ist oder manche

> >Funktionalität vermisst? [...]

> Ich kenne keine, die das nicht ermöglicht. Sowohl in der rpm als
> auch in der dpkg-Welt gibt es sourcepakete die man laden,
> verändern und neu bauen kann. Da muss man aber mit den
> Versionsnummern aufpassen, damit man nicht bei
> Distributionsupdates das neue Paket mit Defaulteinstellungen

> erhält, [...]

Gibt es dafür irgendwo eine (einfach gehaltene) Anleitung? Mein tin
ist (wegen der individualisierten Msg-Id) gepachted; ich achte bei
jedem Update darauf, ihn nicht zu überschreiben bzw. installiere
andernfalls das modifizierte Binary halt noch einmal.

Das durch passende Versionsnummerierung abzustellen wäre angenehm,
aber wenn ich dazu den Kenntnissstand eines dd haben muss, ist es
den Aufwand vermutlich nicht wert :)

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Der einfältige Politiker will Stefan. Kann das Suende sein?
(Sloganizer)

[Marc Haber]

Stefan...@Froehlich.Priv.at (Stefan Froehlich) wrote:
>Das durch passende Versionsnummerierung abzustellen wäre angenehm,
>aber wenn ich dazu den Kenntnissstand eines dd haben muss, ist es
>den Aufwand vermutlich nicht wert :)

Selbst als DD macht man das manchmal falsch, das ist nichttrivial.
Möchte man dass die eigene Version niemals überschrieben wird, macht
man einen Epoch (1.0-1 => 2:1.0-1). Hat man sich eine neue Version
x.y-z aus testing nach stable geholt und möchte beim nächsten stable
direkt wieder in die Releasereihenfolge zurück, nimmt man x.y-z~1 (ist
kleiner als x.y-z). Richtg spaßig wird das dann, wenn man seine
Versionen für unterschiedliche Debian-Versionen vorhalten möchte, da
endet man dann bei Dingen wie x.y-z~zg110.1-1

[Martin Vaeth]

Georg Schwarz <georg....@freenet.de> wrote:
>> Im konkreten Fall etwa in ein von Dir erstelltes Verzeichnis
>> /etc/portage/patches/kde-apps/kmail
>> (da wird der Patch dann bei jedem emerge irgendeiner kmail-Version
>> angewendet) oder
>
> hört sich gut an. D.h. ein entsprechender Mechanismuss für lokale
> Zusatzpatches ist bereits vorhanden und es mussen dafür keine
> Build-Skripte angepasst werden?

Korrekt. Ganz trivial ist es natürlich nur, falls die Patches
einwandfrei anwendbar sind, und falls sich dadurch am Bauen nichts
ändern muss. Und um sicher zu gehen, sollte der Patch mit patch -p1
durchlaufen. (Notfalls kann man aber eine kleine Shell-Datei in ein
anderes Directory stellen, die dafür sorgt, dass das Patchen "manuell"
mit gewünschtem Patch-Level an geeigneter Stelle während des Bauens
passiert. Frag im Gentoo-Forum nach - oder mich - falls Du genauere
Hilfe dazu brauchst.)