[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Vortrag über Paketbau



Am Mittwoch, den 15.06.2005, 23:17 +0000 schrieb Joerg Sommer:

> ich werde heute Abend einen Vortrag über den Bau von .deb-Paketen halten.
> Hier ist meine Präsentation:
> http://www.minet.uni-jena.de/~joerg/vortrag.pdf (Fürs Archiv: Der Vortrag
> zieht später mal auf http://www.lug-jena.de/ um)
> 
> Vielleicht hilft sie ja dem einem oder anderen, einen ersten Einstieg in
> das Thema zu finden.
> 
> Falls noch jemand Verbesserungsvorschläge hat oder Fehler finden, würde
> ich mich freuen.

Da würde ich doch noch einige Vorschläge anbringen wollen:

Seite 3:
- dahinter steht in diesem Fall nicht dpkg, sondern dpkg-deb ('dpkg -c
paket.deb' ruft 'dpkg-deb -c paket.deb' auf) - evtl. in Klammern hinter
dpkg vermerken (man dpkg-deb)

Seite 6:
- native Pakete werden häufig (aber nicht immer) direkt für Debian
entwickelt, das heißt aber nicht, dass sie keinen Upstream haben
- den Teil: single/multi/library/upstream finde ich an der Stelle etwas
unglücklich, da es eigentlich nur Optionen für dh_make sind (um die
richtigen Skripte aus /usr/share/debhelper/dh_make/debian(s|m|l|k) zu
kopieren) und eigentlich nicht in eine generelle Klassifizierung für
Quellpakete fallen -> Quellpakete unterscheidet man IMO nur nach native
und nicht-native.

Seite 9:
- compat muss nicht vorhanden sein, wenn in debian/rules 'export
DH_COMPAT=1-5' gesetzt ist (5 erst mit dpkg 4.9.1)

Seite 10:
- da geht dein Text über den Seitenrand hinaus.

Seite 11:
- bei nativen nur Upstream-, keine Debian-Revision -> für Pakete die
speziell für Debian entwickelt werden ist Upstream- gleichbedeutend mit
Debian-Revision (IMO)
- evtl. kannst du noch NMU aufnehmen (wäre z.B. 0.8-1.1) (Namen in
debian/changelog und debian/control:Maintainers weichen voneinander ab)
- evtl. ein Wort zur Bedeutung der Debian-Revision '-1' verlieren
(.orig.tar.gz wird mit in die .changes-Datei eingetragen und
hochgeladen, ... - für alle anderen müsste '-sa' als Option übergeben
werden)
- testing wird als Distribution akzeptiert, aber wohl nur sehr selten
verwendet (findet vor allem bei der Einordnung in einfache,
automatisierte Repositories wie debpool oder debarchiver Anwendung,
wobei auch hier nach Alternativen gesucht wird, Pakete besser von
unstable -> testing zu verschieben)

Seite 14:
- debian/rules muss ausführbar sein (dh_make legt es richtig an, aber
der Hinweis könnte noch ergänzt werden)

Seite 15:
- Beispiele besser richtig mit 'dh_' angeben: dh_install, dh_installman,
dh_...
- ich würde explizit auf die Man-Seiten dieser Programme + man debhelper
verweisen, da für diese Programme die Man-Seiten doch relativ wichtig
sind (z.B. -a/-i Option und binary-arch/-indep target) und die
Dateiformate package.whatever erklären

Seite 17:
- erster Punkt: '... da es keine java-functions existiert ...' sollte
noch berichtigt werden
- letzter Punkt ist meines Wissens gar nicht konform oder verpönt -
Log-Dateien sollten AFAIK nicht gelöscht werden (IIRC hat Michelle
Konzack mal einen Thread zum Thema gestartet, entweder in
debian-user-german oder debian-mentors - Google könnte evtl. noch helfen
oder Michelle liest das hier)

Seite 18:
- evtl. Paket ergänzen: "gebaut wird mit dpkg-buildpackage (dpkg-dev)"
- evtl. würde ich noch ergänzend die Alternativen bzw. spezialisierten
Programme/Pakete mit aufnehmen:
debuild (devscripts), pdebuild (pbuilder), cvs|svn-buildpackage und
sbuild
- zum Aufräumen: targets in debian/rules sollten ebenfalls mit fakeroot
aufgerufen werden: fakeroot debian/rules target

Evtl. könntest du die relevanten Links zu Info-Quellen am Schluss
präsentieren (auch als erweiterten Lesestoff für interessierte
Paketbauer), u.a.:
- Debian new maintainers guide
- Debian policy
- Debian developers guide
- Debian library packaging guide
- evtl. Repository-Howto +
http://wiki.debian.net/?HowToSetupADebianRepository
(der Vortrag bezieht sich auf das Bauen von Paketen und selbst gebaute
Pakete wird man im Regelfall doch irgendwie verwenden oder anderen zur
Verfügung stellen wollen)

Nur als Hinweis für Seite 19:
- neben lintian existiert linda und wer mit debuild  (devscripts)
arbeitet kann in /etc/devscripts.conf bzw. ~/.devscripts den Aufruf von
Linda und Lintian automatisieren (inkl. übergebener Optionen)
- beim Patch-System sollte natürlich dpatch nicht unerwähnt bleiben
- evtl. wäre dann noch die Einrichtung von pbuilder (und evtl. sbuild)
interessant

MfG Daniel





Reply to: