staging.inyokaproject.org

Gibt es ein Equivalent zu den PKGBUILDs für Debian?

Jein.

Der Paketbau unter Debian ist "leicht" komplizierter und die Konfiguration wird hier über mehrere Dateien geregelt.

▶ http://debiananwenderhandbuch.de/debianpakete.html

Hi Danton,

und hier der Grundlagenartikel in unserem Wiki: Grundlagen der Paketerstellung

Gruss Lasall

Kann mir jemand bitte einen vergleich zum PKGBUILD System gegenüber dem Debian Package System, was habe gegenüber Pacman zu beachten?

EDIT: Habs nun geschafft (mal abgesehen vom Signieren)und habe es auch geschafft das ganze so weit zu automatisieren das ich den debian Ordner für jedes Release verwenden kann und die build Scripts unabhängig vom Paketbau-System zu verwenden sind (ich baue das Programm für Arch und für Debian).

Doch man mir jemand die Unterschiede zwischen den beiden Paket Systemen erklären und erklären warum es so ist?

Hi Danton,

du schriebst:

EDIT: Habs nun geschafft (mal abgesehen vom Signieren)

Siehe die Manpage von debsign.

Doch man mir jemand die Unterschiede zwischen den beiden Paket Systemen erklären und erklären warum es so ist?

Warum das so ist? - Ich zitiere aus Wikipedia zu Arch Linux:

Arch Linux focuses on simplicity and developers meaning that the main effort in assisting the user is not to provide a graphical interface to work with — the package manager, for example, does not have an official graphical front-end — but making well-annotated configuration files and extensive use of shell scripts. This has earned it a reputation as a distribution for "intermediate and advanced Linux users who aren't afraid of the command line".

Relying on complex tools to manage and build your system is going to hurt the end users. [...] "If you try to hide the complexity of the system, you'll end up with a more complex system". Layers of abstraction that serve to hide internals are never a good thing. Instead, the internals should be designed in a way such that they NEED no hiding.
—Aaron Griffin

Kurz: Die Philosophie ist anders. Auf der einen Seite KISS und auf der anderen Seite ein komplexes hochkonfigurierbares Buildsystem.

Die Unterschiede zwischen ABS und dem Debian build toolchain sind bezogen auf die Erstellung von einzelnen Quellpaketen unter anderem Folgende:

• Der Vorteil, den ich im ABS sehe, ist die erheblich einfachere Paketerstellung, was die Wartung, wie z.B. das Upgrade auf neuere Upstreamversionen erheblich erleichtert (meist nur das Austauschen des Upstreamtarballlinks + Checksums). Bei Debianpaketen kommt mindestens noch das Hinzufügen eines Changelog-Eintrags hinzu. Wenn es sich um eine Bibliothek handelt, muss auf die Benennung, das Splitten von Headerpaket und Pakete für die Shared Libraries geachtet werden.

• Es gibt weit über hundert Tools, die das Erstellen von Debianpaketen erleichtern. In erster Linie ist dabei die debhelper Sammlung zu nennen, einer Reihe von Tools, die verschiedene Targets in den Makefiles ausführen, die verschiedene Buildsysteme unterstützen (autotools, cmake, Pythons distutils, Perls Module::Build, usw.), automatisch werden Hooks zum Ausführen für vor oder nach Installation oder Entfernen erstellt, die man natürlich nach Belieben manuell erweitern kann.

• debconf stellt ein Konfigurationssystem zur Verfügung, bei dem der Nutzer vor und oder nach dem Entpacken bzw. dem Entfernen der Installationsdateien interagieren kann.

• Schließlich hat man mit quilt (und ein paar anderen mittlerweile veralteten Tools) vollständige Patchsysteme.

• Quell- und Binärpaketen werden mit Lintian einem weitaus komplexeren Tool als namcap auf mehrere hundert mögliche Ungereimtheiten geprüft.

• Und so weiter und so fort.

Tl;dr, Fazit: Das Debian build toolchain ermöglicht einen erheblichen Einfluss des Maintainers auf den Build/Installationsprozess, wie es mit dem ABS nicht oder nur mit erheblichen Aufwand möglich ist. Ich sehe die User Experience mit dem Debian-Ansatz deutlich besser vertreten, zudem sind die einzelnen Schritte/Tools/Systeme sehr gut dokumentiert.

Gruss Lasall

Lasall schrieb:

[...]

• Der Vorteil, den ich im ABS sehe, ist die erheblich einfachere Paketerstellung, was die Wartung, wie z.B. das Upgrade auf neuere Upstreamversionen erheblich erleichtert (meist nur das Austauschen des Upstreamtarballlinks + Checksums). Bei Debianpaketen kommt mindestens noch das Hinzufügen eines Changelog-Eintrags hinzu. Wenn es sich um eine Bibliothek handelt, muss auf die Benennung, das Splitten von Headerpaket und Pakete für die Shared Libraries geachtet werden.

Changelogs hat Pacman auch und sind nicht erforderlich genauso wie bei Debian auch (habe erst mal keine eingesetzt)

• Es gibt weit über hundert Tools, die das Erstellen von Debianpaketen erleichtern. In erster Linie ist dabei die debhelper Sammlung zu nennen, einer Reihe von Tools, die verschiedene Targets in den Makefiles ausführen, die verschiedene Buildsysteme unterstützen (autotools, cmake, Pythons distutils, Perls Module::Build, usw.), automatisch werden Hooks zum Ausführen für vor oder nach Installation oder Entfernen erstellt, die man natürlich nach Belieben manuell erweitern kann.

• debconf stellt ein Konfigurationssystem zur Verfügung, bei dem der Nutzer vor und oder nach dem Entpacken bzw. dem Entfernen der Installationsdateien interagieren kann.

• Schließlich hat man mit quilt (und ein paar anderen mittlerweile veralteten Tools) vollständige Patchsysteme.

• Quell- und Binärpaketen werden mit Lintian einem weitaus komplexeren Tool als namcap auf mehrere hundert mögliche Ungereimtheiten geprüft.

• Und so weiter und so fort.

Das mag sein diese helfen auch nicht das Distrubtion Spezifische zu umgehen und es zu automatisieren. Ich habe diesen Prozess so weit es geht von diesen Systemen abgeschirmt und in Scripte gepackt so das dass meiste Distrubtion unspezifisch ist (mal abgesehen von den Paketinformationen im Kopf der PKGBUILD bzw in debian/control).

Tl;dr, Fazit: Das Debian build toolchain ermöglicht einen erheblichen Einfluss des Maintainers auf den Build/Installationsprozess, wie es mit dem ABS nicht oder nur mit erheblichen Aufwand möglich ist.

Wie kann ein Maintainer schlechter einen Einfluss auf den Build/Installationsprozess nehmen wenn er das ABS nutzt?

Ich sehe die User Experience mit dem >Debian-Ansatz deutlich besser vertreten

Wo durch?

, zudem sind die einzelnen Schritte/Tools/Systeme sehr gut dokumentiert.

Das ABS ist auch sehr gut Dokumentiert und ermöglicht dem User viel einfacher Pakete zu bauen etwas was auch bei unerfahrenen User sehr von Vorteil sein kann, ich meine so schlau bin ich auch nicht ich bin auch nur eine Schüler in der ITA Ausbildung und finde das Arch gerade bei solchen Dingen viel einfacher ist da es simpler ist.

Gruss Lasall

Grüße Auch

Hi Danton,

du schriebst:

Changelogs hat Pacman auch und sind nicht erforderlich genauso wie bei Debian auch (habe erst mal keine eingesetzt)

Sie sind im ABS nicht erforderlich. Bei Debian sind sie es nach der Policy. Man kann Debianpakete auf verschiedene Art und Weise erstellen (z.B. auch direkt aus der Verzeichnisstrukutr), ich spreche nur von der Policy konformen Variante.

[...]

Das mag sein diese helfen auch nicht das Distrubtion Spezifische zu umgehen und es zu automatisieren. Ich habe diesen Prozess so weit es geht von diesen Systemen abgeschirmt und in Scripte gepackt so das dass meiste Distrubtion unspezifisch ist (mal abgesehen von den Paketinformationen im Kopf der PKGBUILD bzw in debian/control).

Hooks und Trigger sind sehr wohl distributionsspezifisch.

Wie kann ein Maintainer schlechter einen Einfluss auf den Build/Installationsprozess nehmen wenn er das ABS nutzt?

Z.B.: debconf

Ich sehe die User Experience mit dem >Debian-Ansatz deutlich besser vertreten

Wo durch?

Dadurch, dass der Debianmaintainer nicht nur die Upstreamsoftware paketiert, sondern das Paket passend für die Distribution anpasst (und zwar in einer Weise, die nicht dem KISS Prinzip entspricht): Konfiguration, Flags, Abhängigkeiten, debconf, Trigger, usw.

, zudem sind die einzelnen Schritte/Tools/Systeme sehr gut dokumentiert.

Das ABS ist auch sehr gut Dokumentiert und ermöglicht dem User viel einfacher Pakete zu bauen etwas was auch bei unerfahrenen User sehr von Vorteil sein kann, ich meine so schlau bin ich auch nicht ich bin auch nur eine Schüler in der ITA Ausbildung und finde das Arch gerade bei solchen Dingen viel einfacher ist da es simpler ist.

Ich habe nicht ausgeschlossen, dass das ABS gut dokumentiert ist (ist ja nicht so viel zum Dokumentieren 😉 ).

Gruss Lasall

Lasall schrieb:

Hooks und Trigger sind sehr wohl distributionsspezifisch.

Was meinst du hier mit?

Ich sehe die User Experience mit dem >Debian-Ansatz deutlich besser vertreten

Wo durch?

Dadurch, dass der Debianmaintainer nicht nur die Upstreamsoftware paketiert, sondern das Paket passend für die Distribution anpasst (und zwar in einer Weise, die nicht dem KISS Prinzip entspricht): Konfiguration, Flags, Abhängigkeiten, debconf, Trigger, usw.

Abhängigkeiten und Optionale Pakete kann das ABS auch (und sind auch bei 99% der Pakete vorhanden) , bei Konfigurations-Dateien überschreibt dieses die alten (meist) nicht sondern installiert diese mit dem .pacnew bzw. pacsave (nur in Sonderfällen).

Hi Danton,

du schriebst:

Hooks und Trigger sind sehr wohl distributionsspezifisch.

Was meinst du hier mit?

Hooks sind die Maintainerskripte vor/nach/mitten Installation und Deinstallation (Entpacken und Konfigurieren). Trigger sind Aktionen (postinst-Skripte), die ausgeführt werden, wenn ein oder mehrere bestimmtes Verzeichnisse verändert werden. Trigger können vom Maintainer erzwungen werden.

Abhängigkeiten und Optionale Pakete kann das ABS auch (und sind auch bei 99% der Pakete vorhanden) , bei Konfigurations-Dateien überschreibt dieses die alten (meist) nicht sondern installiert diese mit dem .pacnew bzw. pacsave (nur in Sonderfällen).

Komplexe Abhängigkeiten sind mit der Paketverwaltung von Arch nicht möglich, Stichwort "Logische Operatoren".

Btw.: Bitte verwende keine Fullquotes.

Gruss Lasall

Lasall schrieb:

Hi Danton,

du schriebst:

Hooks und Trigger sind sehr wohl distributionsspezifisch.

Was meinst du hier mit?

Hooks sind die Maintainerskripte vor/nach/mitten Installation und Deinstallation (Entpacken und Konfigurieren). Trigger sind Aktionen (postinst-Skripte), die ausgeführt werden, wenn ein oder mehrere bestimmtes Verzeichnisse verändert werden. Trigger können vom Maintainer erzwungen werden.

Das kann das ABS auch PKGBUILD

Abhängigkeiten und Optionale Pakete kann das ABS auch (und sind auch bei 99% der Pakete vorhanden) , bei Konfigurations-Dateien überschreibt dieses die alten (meist) nicht sondern installiert diese mit dem .pacnew bzw. pacsave (nur in Sonderfällen).

Komplexe Abhängigkeiten sind mit der Paketverwaltung von Arch nicht möglich, Stichwort "Logische Operatoren".

Ok das mag sein obwohl || oder && in den Abhängigkeiten schön wären und nicht wirklich nicht KISS wären.

BTW: Es gibt für Pakete im ABS auch Guidlines.

Hi Danton,

du schriebst:

Hooks sind die Maintainerskripte vor/nach/mitten Installation und Deinstallation (Entpacken und Konfigurieren). Trigger sind Aktionen (postinst-Skripte), die ausgeführt werden, wenn ein oder mehrere bestimmtes Verzeichnisse verändert werden. Trigger können vom Maintainer erzwungen werden.

Das kann das ABS auch PKGBUILD

Jein und nein. Die Hooks müssen beim PKGBUILD immer manuell geschrieben werden. Und die Trigger werden immer von dritten Pakete ausgeführt.

Gruss Lasall