Moin!
Letzteres würde dann auch voraussetzen, dass man dann erst die "Service-Plugins" bauen muss und danach die abhängigen Plugins.
Man muss das Service-Plugin nicht bauen, wenn man nur einen Header braucht.
Das ist der Vorteil der -dev-Pakete und sorgt für eine Entkoppelung der Abhängigkeiten. Die -dev-Pakete sind die .h-Dateien eines Projekts. Und über den Sinn von .h-Dateien müssen wir sicherlich nicht streiten...
Dev-Pakete gibt es bei Archlinux per Definition nicht.
Kein Problem. Dann würde ich wie oben schon mal beschrieben ein Paket "Service-Interface" und ein Paket "Service-Plugin" machen, das Plugin-Makefile (nicht *alle* Plugin-Makefiles, sondern nur die, die es anbieten möchten) erstellt beim "make dist" einfach zwei passende Tarballs und schon hat Arch wieder ein Paket pro Quelle. Dabei ist "Service-Plugin" eben abhängig von "Service-Interface".
Aber ich verstehe deinen Standpunkt. Ich möchte mich auch eher an die Plugin-Entwickler richten. Und wenn ich da ein paar finde, mit denen ich mich auf einen gewissen Standard einigen kann, dann reicht mir das.
Das Grundgerüst hätte ich gerne (wie oben schon erwähnt) als Dokumentation im newplugin-Script, aber ich kann auch ohne leben.
Ich werde mich mit meinen Patches dann einfach an die entsprechenden Plugin-Autoren wenden.
Mir war es in erster Linie wichtig, einen gemeinsamen Ort für die Header zu finden, und zumindest da scheint es ja keine Widersprüche zu geben: "$INCDIR/vdr/plugins/$PLUGIN/"
Meine Plugins (die, die es brauchen) werden da ihre Schnittstellen-Header installieren, fertig. Wenn jemand das nutzen möchte (oder es mir nachmachen möchte), würde ich mich freuen.
Oder spricht etwas dagegen, den öffentlichen Teil meiner Plugin-API (die ohne die Plugin-lib auskommt!) allgemein zur Verfügung zu stellen?
Lars.