[Erledigt] Paketabhängigkeiten explorieren

[buhtz]

Zum Paketieren möchte ich durch Ausprobieren herausfinden, welche Abhängigkeiten eine Anwendung benötigt. D.h. ich installiere und schaue dann ob es läuft, oder ob doch noch ein Paket fehlt, dass bisher nicht als Abhängigkeit verzeichnet war.

Das in der Realität zu testen ist schwierig, da man ja immer schon ein installiertes Debian mit diversen Paketen hat. Die bereits installierten Pakete benötigt meine Anwendung vielleicht, sind aber eh schon im Grundsystem installiert, weshalb nicht auffällt, dass diese in der Abhängkeitsliste meiner Anwendung fehlen.

Kann man mir folgen?

Haben die Debian-Maintainer da irgendein Zaubertool, um so etwas besser zu analysieren? Gibt es evtl. so eine Art Minimal-Debian für diesen Zweck, wo wirklich nur soviel installiert ist, dass es gerade so bis zur shell bootet, ohne jeglichen Komfort?

btw: Klar sollte der der Upstream-Maintainer das "einfach" ordentlich dokumentieren. Der bin ich aber auch. Jedoch bin ich die dritte Generation und bin dem Code noch nicht derart vertraut, dass ich sicher alle Abhängigkeiten sehen kann.

[MSfree]

Zum Paketieren möchte ich durch Ausprobieren herausfinden, welche Abhängigkeiten eine Anwendung benötigt.

Ausprobieren ist die denkbar schlechteste Methode. Einen Grund hast du ja schon selbst erkannt, es sind bereits Pakete auf einem System vorhanden, die du auf diese Weise nicht abdeckst.

Code: Alles auswählen

ldd NameDesExecutables

liefert eine Liste von Bibliotheken, die das Executable laden muß, um lauffähig zu sein.

Code: Alles auswählen

apt-file search NameEinerBibliothek

Liefert eine Paketliste, in der die entsprechende Bibliothek zu finden ist, die richtige mußt du dann allerdings noch selbst auswählen.

Sollte das Programm allerdings noch von anderen Paketen abhängig sein, wie z.B. Fonts, der Anwesenheit einer Datenbank, eines Webservers, eines Programmierspracheninterpreter (z.B. Python, Java...), wirst du das mit ldd nicht herausbekommen.

[JTH]

Die Antwort hängt hier ein bisschen von der leider nicht erwähnten Sprache ab, in der das Programm geschrieben ist.

Außerdem macht es einen Unterschied für die Antwort, ob du Abhängigkeiten zum Bauen (Build-Dep) oder zur Laufzeit suchst (Depends).

Build-Deps muss man von Hand listen, da gibt es kein Werkzeug, das einem das pauschal abnimmt. Im Normalfall sollte ein Maintainer das ja von Anfang an wissen und dokumentieren, welche Abhängigkeiten da vorhanden sind. Wenns um C oder C++ geht, könntest du nachträglich nach #include greppen und dann nach den zu den Headern gehörenden -dev-Paketen mit apt-file suchen, wie MSfree vorgeschlagen hat. Für Python etwa gibt es fast keine Build-Deps, außer etwa dh-python, python3, python3-setuptools.

Gibt es evtl. so eine Art Minimal-Debian für diesen Zweck, wo wirklich nur soviel installiert ist, dass es gerade so bis zur shell bootet, ohne jeglichen Komfort?

Hängt wiederum davon ab, ab Bau- oder Laufzeitabhängigkeiten gesucht sind. Um korrekte Build-Deps sicherzustellen – fehlende Build-Deps führen direkt zu Fehlern beim Bauen – kann/sollte man in einer sauberen Buildumgebung bauen. Da gibt es z.B. sbuild; das ist, meine ich, direkt bei Debian aktuell meist verwendet.

Für Laufzeitabhängigkeiten:
Ist das Paket mit Hilfe von debhelper (siehe z.B. hier) und seiner diversen Helferlein paketiert? Wenn nicht, bau es dahingehend um, das nimmt sehr viel Arbeit ab.

Unter anderem nimmt es dir ab, 99% der Laufzeitabhängigkeiten von Hand anzugeben (u.a. genau die, die man mit ldd herausfinden würde, wie MSfree schrieb; die muss man nicht von Hand auflisten). Für ein C- oder C++-Programm reicht da oft ein

Code: Alles auswählen

Depends: ${misc:Depends} ${shlibs:Depends}

in der debian/control. Für ein Python-Programm etwa

Code: Alles auswählen

Depends: ${python3:Depends}, ${misc:Depends}

die Abhängigkeiten werden dann automatisch aus setup.cfg oder der älteren setup.py übernommen und das dazupassende Paket aus dem Debian-Repo eingetragen.

Obiges ginge auch ohne debhelper, braucht dann aber wieder Handarbeit, um die dahintersteckenden Werkzeuge aufzurufen. Mit debhelper braucht man oft wirklich nur diese eine Zeile.

[buhtz]

Danke für eure Antworten, die sehr hilfreich sind. Es geht um Python.

Im Normalfall sollte ein Maintainer das ja von Anfang an wissen und dokumentieren

Das ist wohl im Großen und Ganzen auch passiert; da muss ich die vorhergehenden Maintainer in Schutz nehmen. Aber dass ein oder andere flutschte halt doch durch. Meist Pakete die eigentlich eh schon auf einem (aber nicht allen) System sind; z.B. gettext

Für ein Python-Programm etwa

Code: Alles auswählen

Depends: ${python3:Depends}, ${misc:Depends}

die Abhängigkeiten werden dann automatisch aus setup.cfg oder der älteren setup.py übernommen und das dazupassende Paket aus dem Debian-Repo eingetragen.

Das hilft in meinem Fall nicht, weil es mir um den Schritt davor geht. Ich als upstream muss die Abhängigkeiten ja erst einmal in setup.cfg (bzw. heutzutage eigentlich in pyproject.toml) einpflegen, damit der Distro-Maintainer den von dir genannten Zauberbefehl ausführen kann.

Erschwerend für die Distro-Maintainer kommt hinzu, dass "mein" Python Projekt aktuell keiner Python-Paketierungs-Richtlinie folgt; keine setup.cfg oder ähnliches. Die depends stehen in der README und deb-helper-artigen Bash-Scripten. Wir arbeiten dran!

[JTH]

Aber dass ein oder andere flutschte halt doch durch.

Ja, das kann ich aus jüngster eigener Erfahrung nachvollziehen

Meist Pakete die eigentlich eh schon auf einem (aber nicht allen) System sind; z.B. gettext

Gerade bei solchen, die dann mit der eigentlich verwendeten Programmiersprache nicht direkt etwas zu tun haben, wirst du wahrscheinlich auf dich selbst und ein offenes Auge angewiesen sein. Der einzige Vorschlag, der mir dazu noch einfällt, wären ein paar rudimentäre Tests für deine Anwendung, die dann im Idealfall schon scheitern, wenn solche Abhängigkeiten fehlen. Wenn „richtig“ in den Buildprozess integriert, führt auch debhelper ja wiederum Tests umsonst mit aus.

Das hilft in meinem Fall nicht, weil es mir um den Schritt davor geht. Ich als upstream muss die Abhängigkeiten ja erst einmal in setup.cfg (bzw. heutzutage eigentlich in pyproject.toml) einpflegen, damit der Distro-Maintainer den von dir genannten Zauberbefehl ausführen kann.

Das wär auch im Eingangsbeitrag nicht deplaziert gewesen Habe hier doch primär erstmal an Debian-Paketabhängigkeiten gedacht.

Dann wirds als erstes Zeit für setup.cfg oder pyproject.toml (letzteres ist mit Werkzeugen in Bullseye, meine ich, noch nicht nutzbar, deshalb hab ichs oben unterschlagen). Das nimmt dir ja schon mal einen großen Teil der Arbeit ab.

Um weitere fehlende Python-Abhängigkeiten zu suchen, kann man ja mal nach import greppen. Oder du benutzt eine venv und führst darin die Anwendung aus, das wäre ja zumindest auf Python-Ebene die minimale Grundumgebung, nach der du oben gefragt hast. Auf fehlendes gettext würdest du damit aber nicht stoßen, das nur mit einem Test, der z.B. durch sbuild im chroot ausgeführt wird.

Für Python gibts anscheinend pipreqs (nur per pip) und python3-pipdeptree um Abhängigkeiten anzuschauen. Vllt hilft das noch.