Debian-Paketierung: Organisieren von Quellcode und Paketierungsskripten

Community Coding
1

Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.

2

Debian-Paketierung: Organisieren von Quellcode und Paketierungsskripten
Hi!

Man sehe sich mal folgendes an: https://gitlab.cs.fau.de/re59paxe/fau-openvpn Dort wird in https://gitlab.cs.fau.de/re59paxe/fau-openvpn/blob/master/Makefile#L10 mit fpm das Debian Paket erstellt. Jetzt kann man das aber nicht z.B. auf launchpad hochladen, weil launchpad keine *.deb pakete annimmt.

Wenn man Kontrolle über den Quellcode hat kann man ja einfach einen Ordner “debian” hinzufügen in dem die ganzen Paketierungsdateien liegen. Ein debuild baut dann das Paket. Eine alternative wäre noch ein eigener Branch der dann nur einen extra Ordner hat: den debian/ Ordner.

Wenn man keine Kontroller über den Quellcode hat, muss man ja jedes mal wiede rmit dh_make … anfangen. Das skaliert doch nicht … Eventuell kann man noch ein zweites git repo anlegen mit dem Namen “$PROJEKTNAME-debian” oder so.

Wie macht ihr das so?

3

Warum ein Wrapper fuer OpenVPN? Es gibt ein templatisiertes service-file fuer Debian. Einmal die Konfigurationsdateien (inkl. chain, die config sollte die Endung conf statt ovpn haben) nach /etc/openvpn und dann systemctl start openvpn@FAU-Fulltunnel.

3 „Gefällt mir“
4

Da du deine Paketkonfiguration eh schon in Git verwaltet, könnte git-buildpackage das richtige Werkzeug sein.

5

Wieso ist es immer noch so scheisskompliziert, ein Debianpaket zu produzieren für Software, deren Installation absolut generisch ist? Immer wenn ich irgendeine Anleitung dazu sehe, besteht diese aus gefühlt hundert Seiten und ich gebe wieder auf. Auch bei git-buildpackage ist es wieder das Selbe.

Gibt es vielleicht irgendwo eine Anleitung im Sinne von “Du hast ein CMake-Projekt, führ die folgenden 10 Zeilen aus und schreib hier und da einen Namen und eine Beschreibung rein”, die ich einfach noch nicht gefunden habe?

So schaut es bei Archlinux aus: https://github.com/gerbilvis/aur/blob/master/PKGBUILD

3 „Gefällt mir“
6

Ich versteh immer noch nicht ganz, was du mit „keine Kontrolle über den Quellcode“ meinst. Willst du Binaries paketieren?

Dieses oben erwähnte FPM ist schon relativ einfach, baut aber keine Pakete, die den Debian-Qualitätsstandards entsprechen.
„Richtige“ Debian-Paketierung ist auch nicht übermäßig schwer, wenn man ein paar Grundlagen verstanden hat – ein bisschen länger als das verlinkte Arch-Script ist es schon, aber auch nicht wesentlich (und halt auf mehrere Dateien verteilt). Das Hauptproblem ist m.E. tatsächlich Doku, wirklich gute Anleitung kenn ich entsprechend keine.

7 
mkdir debian
mkdir debian/source
dch --create
echo '3.0 (quilt)' > debian/source/format
echo 9 > debian/compat
cat << EOF > debian/rules
#!/usr/bin/make -f

%:
    dh $@
EOF
cat << EOF > debian/control
Source: baz
Section: utils
Priority: optional
Maintainer: Christoph Egger <christoph@debian.org>
Build-Depends:
 debhelper (>= 9~),
 foo,
 bar

Package: baz
Architecture: any
Depends: \${shlibs:Depends}, \${misc:Depends}
Description: blurp
  boerp
EOF
1 „Gefällt mir“
8

Tsts. In RPM ist das schoener, da ist das nur eine Datei :wink:

9

Und ganz wichtig, nicht vergessen: Es ist nur dann ein echtes Debian-Paket, wenn es bei der Installation auch einen Daemon startet!

10

Wenn es so einfach ist, was war dann so schwer daran, das Gerbil-Paket fertigzustellen, nachdem es ja schon gebaut hat? Keine böse gemeinte Frage, ich will nur gerne wissen, wo die Hürde nun eigentlich liegt, wenn ich das hier mit [m]cat[/m] zusammenbaue…

11

Prinzipiell sollte das so gehen. Vielleicht braucht man noch ein paar mehr Parameter im debian/rules: http://askubuntu.com/questions/166244/packaging-a-cmake-project-librocket-into-a-deb-but-build-script-is-in-a-sub

Aber generell findet ‘dh’ die meisten Sachen von alleine raus, d.h. sollte eigentlich einfach so tun.

12

Ohne alles gelesen zu haben: Bei cmake gibt es auch cpack was vll macht was ihr wollt. Ich habe es mal ausprobiert, hat tatsaechlich ein .deb paket gemacht das man installieren konnte.

13

Wenn CPack auch nur annähernd so “toll” ist, wie CMake, will ich es lieber nicht verwenden ;). Aber danke für den Tipp genauso wie auch den anderen.

1 „Gefällt mir“
14

Es ist zumindest genau so “gut” dokumentiert :slight_smile:

15

Damit meine ich, dass Upstream nicht mein Repository ist. Da habe ich mich wohl etwas bescheuert ausgedrückt.

Weiterhin hab ich gerade noch das Problem dass Upstream ohne Patches nicht sauber baut. Also brauch ich Quilt oder git-dpm (die mir dann vor dem Source Package bauen die Patches einspielen), womit ich mangels guter Doku auch nicht so wirklich weiter komme.

Allein schon die Menge an verschiedenen Werkzeugen ist ein Graus. Kein Wunder dass so viele Pakete Arbeit brauchen und die Paketierer nicht hinterherkommen.

Kennt jemand eine Initiative die das ganze mal ordentlich dokumentiert? Die Debian-Entwickler machen es ja nicht. Warum?