Reform der APIVERSION?

  • Jedes Mal, wenn es eine neue VDR-Version gibt, bei der die APIVERSION nicht hochgezählt wird (weil sich das API nicht geändert hat), kommt wieder das Argument, dass es "irritierend" sein, wenn VDRVERSION und APIVERSION sehr ähnlich, aber doch nicht gleich sind. Und es sollte doch APIVERSION eine ganz andere Zahl sein, damit das vermieden wird. Setze ich APIVERSION immer gleich VDRVERSION, sind diese Nutzer dann zwar still, aber dann jammern (zurecht) jene, die viele Plugins verwalten und diese dann jedes Mal neu übersetzen müssen. Ich bin da dann auch jedes Mal hin- und hergerissen (wie man vielleicht an meinen Reaktionen sehen kann ;)).

    Um vielleicht endlich mal Frieden in diese Angelegenheit zu bringen, greife ich mal den Vorschlag auf, einfach eine laufende Nummer für APIVERSION zu verwenden. Dazu folgende Gedanken:

    1. APIVERSION soll sich auch in APIVERSNUM widerspiegeln.
    2. APIVERSNUM muss auch in der neuen Variante gößer als 20609 sein.
    3. APIVERSION wird an allen Stellen als einfacher String behandelt, kann also beliebigen Inhalt haben.
    4. Wenn man mal in /usr/lib reinschaut sieht man, dass *.so-Dateien üblicherweise Versionsnummern haben, die aus drei durch Punkte getrennte Zahlen bestehen (daher auch das bisherige Format bei APIVERSION). Es gibt aber auch welche mit zwei Zahlen oder nur einer (letzteres meist Symlinks).
    5. APIVERSION könnte also eine einfache Zahl sein, ohne den Ablauf zu stören (habe ich getestet).
    6. Bisher gab es für die Plugins Dateien mit Namen libvdr-*.so.1.?.? und libvdr-*.so.2.?.?. Das neue Format sollte meiner Meinung nach mit libvdr-*.so.3 beginnen, um zumindest hier eine gewisse Kontinuität einzuhalten.
    7. Diese Aktion darf keine Änderungen in Plugin-Code (weder Source noch Makefile) verursachen.

    Unter Berücksichtigung all dieser Punkte wäre folgende Lösung möglich:

    Code
    #define APIVERSION      "3"
    #define APIVERSNUM   30003

    Damit ergäben sich Dateinamen wie etwa libvdr-osddemo.so.3.

    APIVERSNUM braucht die 3 am Anfang, um Punkt 2 von oben zu erfüllen.

    Die nächste API-Version sähe dann so aus:

    Code
    #define APIVERSION      "4"
    #define APIVERSNUM   30004

    Alle bisherigen #if APIVERSNUM < NNNNN Abfragen im Code bleiben davon unberührt.

    Die bisherige Möglichkeit, an einer solchen Stelle sofort sehen zu können, bei welcher VDR-Version sich das geändert hat, geht allerdings für künftige Werte von APIVERSNUM verloren.

    Irgendwann wird VDRVERSNUM (momentan 20701) in den Bereich von APIVERSNUM kommen, aber das spielt sich nur Code-Intern ab und schlägt nicht auf die Dateinamen durch. Und bis dahin sind es noch mindestens 29 Versionen (wenn ich mich nicht verrechnet habe) ;).


    Ich bitte um Meinungen hierzu, vor allem, ob ich etwas Wichtiges übersehen habe.

  • APIVERSNUM muss auch in der neuen Variante gößer als 20609 sein.

    Macht Sinn falls Plugins gezielt auf APIVERSNUM Preprozessor-Instruktionen hängen wollen.


    Die bisherige Möglichkeit, an einer solchen Stelle sofort sehen zu können, bei welcher VDR-Version sich das geändert hat, geht allerdings für künftige Werte von APIVERSNUM verloren.

    Geht mit "git blame" recht einfach das auf ein Commit und so auch auf einen Zeitrahmen einzugrenzen.


    Für mich klingt das nach einem verdammt guten Vorschlag. Passt damit auch besser zu anderen Libraries die nach interner Struktur versioniert werden und nicht nach der Version der Software, die die Library nutzt.

  • finde ich gut

    (VDR) NUC11PAH & GEEKOM MINI-IT11-11. Generation * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2022) *

    (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65G29LA

  • Wäre eine Deprecation von APIVERSNUM denkbar? Was auch immer Plugins beim Übersetzen damit machen, ließe sich auch mit APIVERSION lösen (auch jetzt schon). Einzig die Verwendung innerhalb von SVDRP (wegen Peering?) müsste man sich mal genauer ansehen.

  • Irgendwann wird VDRVERSNUM (momentan 20701) in den Bereich von APIVERSNUM kommen, aber das spielt sich nur Code-Intern ab und schlägt nicht auf die Dateinamen durch. Und bis dahin sind es noch mindestens 29 Versionen

    Und dann geht die Diskussion wohl wieder von vorne los. Warum nicht gleich einen mutigen Schritt wagen: Nachdem heutzutage ja praktisch jeder Compiler 32-bittig ausgelegt ist, sind Integer-Werte (sieht man einmal vom – unter Linux wohl kaum genutzten – Datenmodell LP32 ab) im Bereich ±231, also ca. ±2G. Damit könnten wir doch folgende Definition nutzen:

    Code
    // the sole definition of the API version identifier
    #define APIVERSIONID      3
    // the derived constants
    #define QUOTE( v )        #v
    #define APISTRING( v )    QUOTE( v )
    #define APIVERSION        APISTRING( APIVERSIONID )    // for backward compatibility
    #define APIVERSBASE       1000000                      // or (1 << 28) for nice hex
    #define APINUMBER( v )    (APIVERSBASE + (APIVERSIONID))
    #define APIVERSNUM        APINUMBER( v )

    Mit dieser Basis ist die kodierte Versionsnummer bestimmt auf "auf ewig" kollisionsfrei.


    Das Konstrukt ist zwar ein bisschen umfangreicher als die zwei Zeilen bisher. Aber dafür hat man nur noch eine einzige Stelle, an der die API-Version definiert wird (somit also keine Redundanz) und kann man mit dem Makro APINUMBER() die APIVERSNUM unabhängig von ihrer internen Codierung in Präprozessor abfragen:

    Liefert: API version: "3", 1000003 (0x000F4243), exit code 0


    Dieser Ansatz ist zudem unabhängig davon, wie die Basisnummer gewählt ist, sofern sie nicht kleiner ist als die derzeitige APIVERSNUM, sprich: 20609. Dass die "kodierte" Versionsnummer (also Basis + API-Version) im Code nicht mehr in Erscheinung tritt, wäre ein weiterer Vorzug.


    Was meint ihr?


    Danke & Grüße

    Stefan

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.3 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

    Edited 4 times, last by shofmann ().

  • [optional]


    {VDR,API}VERSION könnte entfallen und durch Funktionen ersetzt werden, die aus {VDR,API}VERSNUM diese strings generieren.

    Kein Grund, das zur compile time zu ermitteln, weil "ist ein String, damit sind Abfragen wie" (..) "nicht möglich.". Dann aber möglichst auch vom uppercase weg, um von macros/defines zu unterscheiden.


    [/optional]




    Was ich btw. nicht verstehe, wenn sich denn die API von 2.6.9 zu 2.7.1 so gar nicht geändert hat, wie können so viele Plugins 'fail to compile'? Ist es nicht eher doch so, dass die API hätte erhöht werden müssen, weil eben jene convenience macros nun weg sind? (Zusatzfrage, hätten die nicht per default einen build verhindern sollen, sobald etwas deprecated ist?)


    Und würden nicht all diese Plugins vom 2.6.9, wenn denn nicht neu gebaut weil kompatibel zu 2.7.1, irgendwann einen segfault bringen müssen?

  • wirbel Wahrscheinlich wäre es tatsächlich sinnvoll gewesen, in der 2.7.1 auch APIVERSION zu erhöhen. Ich bin halt irgendwie davon ausgegangen, dass nach all den Jahren die deprecateten Funktionen nicht mehr benutzt werden. Da muss ich wohl künftig vehementer sein ([[deprecated]]).


    Was mich interessieren würde: gab es Plugins, die DEPRECATED_CFILE=1, DEPRECATED_SKIN_SETITEMEVENT=1 oder DEPRECATED_SETCURRENTCHANNEL=1 gesetzt haben? Diese Codeteile waren nämlich defaultmäßig schon länger disabled.


    Bei DEPRECATED_SCHEDULE_GET_EVENT, DEPRECATED_SECTIONSYNCER_SYNC_REPEAT und DEPRECATED_CCONTROL wurde der Wert von 1 auf 0 gesetzt, um die Entwickler mit der Nase draufzustoßen, dass hier Handlungsbedarf besteht. Diese Files mussten also auf jeden Fall neu übersetzt werden, entweder, indem die nötigen Änderungen gemacht werden, oder indem (als kurzfristige Notlösung) das entsprechende Macro wieder auf 1 gesetzt wird.


    {VDR,API}VERSION könnte entfallen und durch Funktionen ersetzt werden

    {VDR,API}VERSION werden vom Makefile aus config.h extrahiert, das muss also ein String sein.


    Ich habe noch einen Punkt 7. in meiner Liste hinzugefügt:

    Diese Aktion darf keine Änderungen in Plugin-Code (weder Source noch Makefile) verursachen.

  • Mir wäre DEPRECATED_FOO_BAR ohne default lieber, Plugin maintainer/Entwickler hätten sofort die Info und nicht erst Jahre später. Da waren Änderungen von 2.4.2 bei..


    #ifdef DEPRECATED_FOO_BAR

    /* deprecated: see 2.4.2:HISTORY */

    (..)

    #endif

  • Nur scheitert er bereits daran, dass {VDR,API}VERSION vom Makefile aus config.h extrahiert werden, das müssen also "echte" Strings sein.


    Im Makefile des VDR findet sich diese Zeile:

    Code
    APIVERSION = $(shell sed -ne '/define APIVERSION/s/^.*"\(.*\)".*$$/\1/p' config.h)

    Bei dem vorgestellten Ansatz bräuchten wir künftig dann APIVERSIONID, denn die geht ja in die Namen der Shared Libs ein. Aus:

    Code
    install -D $$l $(LIBDIR)/`basename $$l`.$(APIVERSION)

    … wird künftig dann ja:

    Code
    APIVERSIONID = $(shell sed -ne '/define APIVERSIONID/s/^.* \([0-9]*\).*$$/\1/p' config.h)
    ...
    @echo "apiversion=$(APIVERSIONID)" >> $@
    ...
    install -D $$l $(LIBDIR)/`basename $$l`.$(APIVERSIONID)

    Und die Makefiles der Plugins benötigen genau diese APIVERSIONID aus vdr.pc, um den Namen der Shared Libs bei der Installation richtig zu setzen. Hier der Auszug aus dem Makefile des Plugins Live:

    Code
    ### The version number of VDR's plugin API:
    APIVERSION := $(call PKGCFG,apiversion)
    ...
    ### Installed shared object file:
    SOINST := $(DESTDIR)$(LIBDIR)/$(SOFILE).$(APIVERSION)

    Wir hatten vor Jahren mal eine Phase, in der so gut wie alle Makefiles umgestellt werden mussten. Deshalb gehe ich davon aus, dass fast alle (wenn nicht sogar alle) sich die Information aus vdr.pc holen. Wenn nicht, wäre es Zeit, sie endlich auf den aktuellen Stand zu bringen.


    Wenn mein Bild nicht ganz falsch ist, müsste der Ansatz doch machbar sein.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.3 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

    Edited once, last by shofmann ().

  • {VDR,API}VERSION werden vom Makefile aus config.h extrahiert, das muss also ein String sein.


    Ist kein Macro, was für compile time Vergleiche verwendet werden kann, wird überall nur als ein const char* verwendet.


    #define VDRVERSION VdrVersion()

    #define APIVERSION ApiVersion()

    const char* VdrVersion(void) { /* using VDRVERSNUM */ (..) }

    const char* ApiVersion(void) { /* using APIVERSNUM */ (..) }

  • Jedes Mal, wenn es eine neue VDR-Version gibt, bei der die APIVERSION nicht hochgezählt wird (weil sich das API nicht geändert hat), kommt wieder das Argument, dass es "irritierend" sein, wenn VDRVERSION und APIVERSION sehr ähnlich, aber doch nicht gleich sind.

    Ich habe mich da vermutlich zu verkürzt ausgedrückt - mir ging es vor allem darum, dass die API-Version praktische Kompatibilität signalisiert - und wenn die ohne Rücksicht auf die Werte von Defines wie DEPRECATED_SCHEDULE_GET_EVENT, DEPRECATED_SECTIONSYNCER_SYNC_REPEAT und DEPRECATED_CCONTROL unverändert bleibt, dann passt die API des gebauten VDR einfach nicht zu allen Plugins, die gegen den den VDR 2.6.9 gebaut wurden.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Um das Ganze abzukürzen: kommt dein Vorschlag ohne Änderungen in bestehendem Plugin-Code aus?

    Kann ich nicht einschätzen, denn ich kenne nur einige davon. Doch ich bin optimistisch:

    • Neue Versionsabfragen können das neue Schema nutzen.
    • Alte Versionsabfragen sollten weiterhin funktionieren.
    • Makefiles nach dem "neuen" Schema (siehe oben) sollten passen.

    Letztlich müsste man es wohl mal ausprobieren.


    PS: Ich habe seinerzeit bei mir alle Makefiles konsequent auf das neue Schema umgestellt und nutze ausschließlich diese, selbst wenn Plugin-Maintainer ihre Makefiles nicht umgestellt oder meine damals geposteten Patches übernommen haben. Insofern kann ein Test bei mir lokal natürlich klappen, wohingegen ein abweichendes "originales" Makefile vielleicht an der Extraktion der Versionsnummer aus config.h scheitert. In diesem Fall würde ich aber eher dafür plädieren, die Makefiles alten Plugins endlich auf den aktuellen Stand zu bringen als eine Evolution daran scheitern zu lassen.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.3 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

    Edited once, last by shofmann ().

  • In diesem Fall würde ich aber eher dafür plädieren, die Makefiles alten Plugins endlich auf den aktuellen Stand zu bringen als eine Evolution daran scheitern zu lassen.

    Das setzt aber voraus das jemand die Arbeit macht. Ich unterstütze ja gerne und mittlerweile ist das zumindest in der Theorie einfacher denn je, weil man eigentlich für jedes Plugin auch ein Repo hätte. Aber dafür müsste auch jemand Pull-Requests auf https://github.com/vdr-projects anlegen, denn so gerne ich auch wollen würde: Die Zeit, hier Patches einzusammeln und in die verschiedenen Repos zu committen habe ich einfach nicht mehr.


    Edit: Wobei ich absolut keinen Überblick habe ob es tatsächlich noch relevante Plugins mit altem Makefile gibt. Ich hatte selber mal ein paar angepasst die bei vdr4arch mitgebaut werden. Aber z.B. bei yaVDR sind ja viel mehr Plugins dabei. Vielleicht kann man sowas mit ein paar kreativen "greps" auswerten um zu wissen wie viele alte Makefiles noch im Umlauf sind?

  • Letztlich müsste man es wohl mal ausprobieren.

    OK, ich habe mal die folgenden Patches auf VDR 2.7.1 angewandt:

    … und damit alles neu gebaut. Hier die vdr.pc:

    Mit den Makefiles nach neuem Stand lief alles problemlos durch. Hier die Binaries:

    Bleibt anzumerken, dass xineliboutput schon ewig libxineliboutput-*.so.2.2.0 installiert, hier zum Beispiel beim VDR 2.6.7:

    Code
    ...
    libvdr-undelete.so.2.6.7
    libvdr-xineliboutput.so.2.6.7
    libxineliboutput-fbfe.so.2.2.0
    libxineliboutput-sxfe.so.2.2.0
    libxineliboutput-wlfe.so.2.2.0

    Das hat also nichts mit der Änderung zu tun.


    PS: Einige Makefiles enthalten noch einen Kompatibilitätsabschnitt, der sich – wenn die APIVERSION[/tt nicht per pkgconfig abrufbar ist – diese über die Verzeichnishierarchie aus den VDR-Headern extrahiert. Diese Abschnitte waren hier inaktiv, sollten entweder entfernt oder müssten bezüglich der Extraktion der [tt]APIVERSION – ähnlich wie im obigen Patch – nachgezogen werden.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.3 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

    Edited once, last by shofmann ().

  • Die Zeit, hier Patches einzusammeln und in die verschiedenen Repos zu committen habe ich einfach nicht mehr.

    das kann ich wunderbar verstehen - aber weshalb nicht einfach alte zoepfe abschneiden.

    bin ueberzeugt, dass jede menge plugins irgendwie am leben gehalten werden,

    damit sie compilieren und starten, aber genutzt werden sie von niemandem mehr.


    daher alles, was ab vdr 2.4.2, innerhalb der der zu diskutierenden zeit (2 monaten) nicht mehr baut

    und funktioniert, ab in die tonne. da wird viel rausfallen


    das wuerde auch vdr-anfaengern entgegenkommen

  • Super, dass schon so viele Experten diese Diskussion hier führen und Laien wie ich mitlesen können.

    Obwohl mir noch ein paar bekannte Namen abgehen, bin ich sicher, ihr werdet euch diesmal auf eine Variante einigen, die dann von "allen" Experten/Maintainern auch für gut befunden wird.

    Danke jedenfalls für euren regen Einsatz und die spannende Diskussion!!!

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!