deb make und Konsorten (was: Re: [Debian]: Wie werde ich Package-Maintainer?
Hallo,
da Manoj ja nicht die deutsche Liste liest, übernehme ich jetzt einfach mal
den Part, vor debmake und Konsorten zu warnen :)
On Fri, Nov 13, 1998 at 05:54:23PM +0100, Volker Ossenkopf wrote:
[...]
> Soweit es Lizenzmaessig machbar ist solltest Du stets auch ein
> Source-Paket bauen. Schau Dir zur Hilfe mal debmake an.
> debmake kann Dir viel Arbeit abnehmen
Zur Erklärung für diejenigen, die debmake nicht kennen:
Deb make ist ein Programm, welches einige Standardaufgaben eines
ordedntliche Debian rules script übernimmt. Das rules script erstellt ein
Paket aus den Sourcen (es kompiliert, packt zusammen, ergänzt, schiebt
Dateien herum, setzt ownership und permissions zubd ähnliches).
Viele Dinge sind durch die Debian Policy festgelegt: Besitzer und
Zugriffsrechte auf Dateien, Ort von bestimmten Dateien (z.B. Dokumentation,
menu system), bestimmte Elemente der Installationsskripte, komprimierung von
Dokumentation, Entfernung von Debug Symbolen in Binaries, etc. Liegt es da
nicht Nahe, diese Aufgaben vom Computer automatisch erledigen zu lassen?
Debmake war ein Versuch, dies zu tun. Unglücklicherweise ist das Design von
debmake nicht dazu geeignet, dem Paketverwalter zur Selbsthilfe zu helfen:
Es ist ein einziges Programm, welches eine Reihe von Aufgaben durchführt,
ohne daß der unbefleckt, frischgebackene Maintainer begreift was eigentlich
alles genau passiert. Dieser Nachteil verstärkt sich dann, wenn Probleme
auftauchen. Das ist wie in Windows: Wenn Windows irgendetwas partout falsch
macht, weiß man nie, wo man ansetzen muß um das Problem zu beheben.
Das ist der Grund, warum debmake zwar bei Einsteigern beliebt war, bei
erfahrenen Debianern aber nie. Zudem häuften sich die Probleme mit Debmake,
und es wurde aufgegeben. Debmake befindet sich in einem Tiefgefrorenen
Zustand: Offensichtliche Fehler werden behoben, aber es wird nicht
verbessert.
Deb Helper ist da schon einiges weiter, denn es teilt die zu leistende
Arbeit auf in viele kleine Scripte. Ich habe nur ein Paket jemals mit
debmake erstellt, aber drei Pakete mit debhelper. Das zeigt, das ich
debhelper akzeptabler finde als debmake :)
Heute jedoch sind alle meine rules files handgeschrieben, ohne auf
helferskripte zurückzugreifen. Warum?
+ Helferskripte sind Black boxes. Selbst im Fall von debhelper (wo alle
aufgerufenen Befehle auf dem Bildschirm erscheinen, und die Aufgabe auf
viele kleine Skripte verteilt sind) kann ich nur das Skript aufrufen, oder
es sein lassen. Eine feine Kontrolle auf der Basis einzelner Dateien wird
umständlicher, weil ich erst das Skript aufrufen muß, und dann nachträglich
Korrekturen vornehmen muß.
+ Ich lerne mehr. Weil ich mich nicht mehr auf die Helferskripte verlasse,
lerne ich, wie eine Aufgabe mit den Standard Unix Tools gelöst wird.
+ Es ist einfacher zu modifizieren. Mit debhelper muß man Dateien pflegen,
die zum Beispiel eine Liste aller zu kopierenden Dateien beinhalten. Dies
Zerpflückung des rules script in rules makefile und Konfigurationsdateien
ist unübersichtlich, und ich muß mehrere Dateien editieren. Ohne
Helferskripte ist alles in einer Datei.
+ Die Skripte sind einfacher für andere zu verstehen. Nicht jeder kennt
debhelper oder debmake. Kaum einer außerhalb von Debian hat jemals davin
gehört. Meine rules files sind standard makefiles, die auf jedem Unix
system laufen. Dies macht es auch einfacher, die Pakete auf andere
Plattformen zu portieren. (Andernfalls müßte man erst einmal debhelper
kopieren. Glücklicherweise ist es in perl geschrieben)
+ Bei einem single-binary Paket mag debhelper noch einfach zu benutzen
sein. Wer aber Pakete verwaltet, die aus einer einzigen Source stammen,
mit shared libraries, development files, binary independent and binary
architecture gemischt, weiß warum ich handgeschriebene rules files leichter
zu verwalten finde :)
Das sind nur einige wenige Gründe, und keiner ist unangreifbar. Aber
zusammengenommen sind sie stark genug um mich davon zu überzeugen, daß
helper skripte unnötig sind (besonders da wir jetzt zur Überprüfung der
Policy ein eigenes Tool haben, lintian).
Ich denke, es ist eine gute Idee, mit debhelper einzusteigen, und dann nach
und nach die Debhelper skripte durch eigene Kommandos zu ersetzen. So wird
man von der Arbeit nicht erschlagen, sondern kann nach und nach dazulernen.
Beispielhaft rules files könnt ihr vom Power Maintainer Manoj Svrivastava.
Er ist der "make" maintainer, und weiß wie man mit makefiles umgeht :) Seine
Skripte sind erhältlich von der Debian Developers Corner, IIRC.
Debmake sollte jedoch in die Bedeutungslosigkeit verkümmern, je eher, desto
besser. Einsteiger solten sich darauf auf keinen Fall einlassen.
Marcus
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie
bitte eine E-Mail an majordomo@jfl.de die im Body
"unsubscribe debian-user-de <your_email_address>"
enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@jfl.de
------------------------------------------------
Anzahl der eingetragenen Mitglieder: 637
Reply to: