[solved] Welches libcurl4-???-dev nimmt man denn?

  • Moin,

    ich baue mir die debs selber und bin dabei gestern wieder auf das Problem gestossen , das diverse Plugins da verschiedene Abhängigkeiten in debian/control eingetragen haben, die nicht zusammen passen. Nun habe ich erstmal alle mit 'libcurl4-openssl-dev' gebaut, was augenscheinlich auch gut funktioniert.


    Fragen sind nun:

    - Warum nimmt da jeder was anderes?

    - Welche Version ist die beste/sinnvollste?


    Server läuft mit Ubuntu, die Clients mit Raspbian.


    MfG

  • ich baue mir die debs selber und bin dabei gestern wieder auf das Problem gestossen , das diverse Plugins da verschiedene Abhängigkeiten in debian/control eingetragen haben, die nicht zusammen passen.

    Gibt es bei den yaVDR-Paketen in der Hinsicht noch Inkonsistenzen? Ich baue die Pakete mit dem pbuilder, da hat man für jedes Paket ein sauberes Build-Environment und solange die Abhängigkeiten der erzeugten Pakete nicht kollidieren, ist es egal, ob die Header-Bibliotheken, die von unterschiedlichen Paketen als Build-Dependencies benötigt werden, parallel installiert sein können.

    - Welche Version ist die beste/sinnvollste?

    Das hängt davon ab, welche Features du haben willst: https://curl.haxx.se/docs/ssl-compared.html

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ja, da gibt es noch Inkonsistenzen. Das hatte ich auch ganz grob hier schon mal angesprochen, aber konkret:



    Also 'libcurl4-nss-dev' vs. 'libcurl4-gnutls-dev' vs. 'libcurl4-openssl-dev' und ' libmysqlclient-dev' vs. 'libmariadbclient-dev'


    Und vielen Dank für deine ausführliche Antwort. Das mit dem pbuilder kannte ich noch nicht und werde ich definitiv probieren. :thumbup:

  • Hallo,


    danke für das anpassen der build-dependency. Der Einfachheit halber habe ich mich auch für libcurl4-openssl-dev entschieden.


    pbuilder bin ich am testen. Hast du da noch eine Anleitung parat, wie ich die Pakete jetzt sauber anpassen kann.

    Wie muss ich vorgehen, wenn ich zB den permashift Patch loswerden will?


    Bisher habe ich einfach den vdr entpackt, ge-patched, Debian Verzeichnis rein kopiert und :

    Code
    1. dch -l "~local" "adopt patches"
    2. dpkg-buildpackage -b -us -uc

  • Um Patches zu verwealten, solltest du dir das Paket quilt installieren und eine ~/.quiltrc anlegen: https://wiki.debian.org/UsingQ…uiltrc_configuration_file - ich würde die "Encapsulated" Variante nehmen.


    Dann holst du dir die Sourcen für das VDR-Paket und geht in das Verzeichnis:

    Code
    1. apt-get source vdr
    2. cd vdr-2.3.9*

    Als erstes machst du alle Patches, die in debian/patches/series definiert sind, rückgängig:

    quilt pop -a und löschst den Permashift-Patch: quilt delete -r vdr-2.3-patch-for-permashift.diff

    Dann musst du die nachfolgenden Patches gerade ziehen - das geht mit while quilt push; do quilt refresh; done (das zieht die Zeilennummern automatisch gerade, wenn ein Patch nicht mehr ganz passt).

    Falls es rejects gibt, kannst du mit quilt push -f das Anwenden eines Patches erzwingen und die Source-Datei und die dazugehörige Datei mit der Endung .rej öffnen, den reject auflösen und dann mit quilt refresh den Patch aktualisieren.


    Sobald alle Patches angewendet wurden, solltest du mit python debian/patchcheck.py -c prüfen, ob die Patches passen und mit python debian/patchcheck -u den neuen Patchstand übernehmen. Da sich durch den Wegfall des Patches die ABI des VDR geändert hat, solltest du außerdem die ABI-Version in debian/abi-version erhöhen.


    Danach kannst du das Paket bauen. Wenn du dpkg-buildpackage mit -b aufrufst, musst du darauf achten, dass zu dem Zeitpunkt alle Patches angewendet wurden (quilt push -a), sonst werden die beim Bauen ignoriert.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    The post was edited 1 time, last by seahawk1986 ().

  • Ok, jetzt bin ich schon ein gutes Stück weiter aber so ganz hab ich es noch nicht verstanden.


    Was ist, wenn ich anstatt dpkg-buildpackage dann den pbuilder verwenden möchte?

    Nachdem ich die Patches entfernt bzw deine Anleitung bis zum erhöhen der ABI-Version abgearbeitet hatte, habe ich mal sudo pbuilder build *.dsc aufgerufen. Das hat leider alles wieder zurückgesetzt:


    Dann stellt sich mir noch die Frage, wie die Plugins über das neue Patchlevel informiert werden.

    Wenn ich dpkg-buildpackage verwende kann ich ja einfach das vdr-dev Paket installieren, aber wie funktioniert das dann mit dem pbuilder?

  • Wenn du pbuilder mit einer .dsc Datei aufrufst, musst du erst eine .dsc-Datei haben, die den neuen Stand wiederspiegelt. Wenn du pdebuild im Source-Verzeichnis für das Paket aufrufst, macht es das für dich automatisch.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Bei der abi-Version am besten dann yavdr durch saman ersetzen, damit es keinen Konflikt gibt, wenn wir mal die Version erhöhen und die dann zufällig gleich ist, aber was anderes widerspiegelt.


    Lars

  • Jetzt habe ich mein eigenes vdr_2.3.9-5saman0~bionic_amd64.deb :)


    Mir fehlt nur noch der letzte Schritt.

    Wie baue ich jetzt mit dem pbuilder die passenden Plugins dazu?


    Für den schnellen Snack zwischendurch, werde ich am Ende sowieso das vdr-dev_2.3.9-5saman0~bionic_amd64.deb installieren, aber das ist dann ja kein 'sauberes Build-Environment' mehr (das ist eher eine Verständnis-Frage, um den korrekten Weg nachzuvollziehen).


    Ich könnte zB die debs in mein lokales Repository packen, aber wie weiss dann der pbuilder, das er mein neues vdr-dev benutzen soll?

    Zieht der dann einfach das verfügbare Paket, mit der höchsten abi-version?

    The post was edited 1 time, last by Saman ().

  • aber wie weiss dann der pbuilder, das er mein neues vdr-dev benutzen soll?

    Du übergibst ihm das lokale Repository in der ~/.pbuilderrc als zusätzliche Paketquelle und aktualisierst danach die pbuilder-Konfiguration mit sudo pbuilder --update --override-config


    Es gewinnt immer das vdr-dev Paket mit der höchsten Versionsnummer (es sei denn du machst in den Build-Dependencies der Plugins explizit Versionsangaben). Das PPA mit den yaVDR VDR Paketen musst du ja nicht in die Liste aufnehmen, wenn du eine eigene Paketquelle aufmachst (aber ppa:yavdr/experimental-main bietet sich an, wenn du die benötigten Pakete nicht auch alle lokal bauen lassen willst), damit musst du nur aktueller sein als das vdr-dev Paket in den regulären Ubuntu-Paketuquellen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Super!


    Habe jetzt auch noch was gefunden: https://wiki.debian.org/PbuilderTricks


    Nachher werde ich noch versuchen, das er die Sourcen für den skindesigner und tvguideng auch gleich aus meinem git zieht.

    Letztlich, beim bauen des osdteletext-plugin, habe ich da sowas über den Bildschirm huschen sehen...

  • Danke für den Link!


    Ich habe jetzt die ersten Plugins gebaut, allerdings funktioniert es nicht mit jedem:

    ~/.pbuilderrc

    Code
    1. PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-gdebi"
    2. ALLOWUNTRUSTED="yes"
    3. OTHERMIRROR="deb [trusted=yes] file:///var/local/packages ./|deb [trusted=yes] http://ppa.launchpad.net/yavdr/experimental-main/ubuntu bionic main"
    4. BINDMOUNTS="/var/local/packages"


    Edit: dpkg-buildpackage -b -us -uc läuft durch.

    The post was edited 1 time, last by Saman ().

  • Könnte das ein (altbekannter) Bug von gdebi sein? https://bugs.launchpad.net/gdebi/+bug/396684


    Ich habe meine pbuilder-Konfiguration ausgehend von https://filthypants.blogspot.d…pbuilder-to-act-like.html aufgebaut, damit sich das möglichst wie Launchpad verhält:

    Damit baut das Paket ganz brav: pbuilder_satip.log.txt

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-gdebi" war der Übeltäter.


    So sieht das jetzt bei mir aus:

    Ohne [trusted=yes] läuft es nicht.