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.