[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ weiter ]

Anleitung für zukünftige Debian-Maintainer
Kapitel 5 - Benötigte Dinge in debian/


Es gibt nun ein neues Unterverzeichnis 'debian' im Hauptverzeichnis des Quellcode-Pakets, in dem bereits einige Dateien liegen. Wir werden diese ändern, um die Eigenschaften des Pakets anzupassen. Die wichtigsten Dateien sind `control', `changelog', `copyright' und 'rules', die für die Erstellung jedes Pakets benötigt werden.


5.1 Die Datei `control'

Diese Datei enthält verschiedene Werte, die dpkg, dselect und andere Paketverwaltungs-Tools für die Paketverwaltung benötigen.

Das ist die Datei `control', die dh_make für uns erstellt hat:

     1  Source: gentoo
     2  Section: unknown
     3  Priority: optional
     4  Maintainer: Josip Rodin <joy-mg@debian.org>
     5  Build-Depends: debhelper (>> 3.0.0)
     6  Standards-Version: 3.5.2
     7
     8  Package: gentoo
     9  Architecture: any
     10 Depends: ${shlibs:Depends}
     11 Description: <insert up to 60 chars description>
     12  <insert long description, indented with spaces>

(Zeilennummerierung habe ich für dieses Beispiel hinzugefügt.)

Zeilen 1-6 sind Steuer-Informationen für das Quellcode-Paket.

Zeile 1 ist die Bezeichnung des Quellcode-Pakets.

Zeile 2 bestimmt die Sektion der Distribution, in die das Quellcode-Paket gehört.

Sie haben bestimmt schon gemerkt, dass Debian in Sektionen aufgeteilt ist: main (die freie Software), non-free (nicht wirklich freie Software) und contrib (freie Software, die von non-free-Sachen abhängt). Unterhalb dieser Sektionen existieren logische Untersektionen, die eine minimale Beschreibung des Pakets geben. D.h. die Sektion `admin' enthält Programme für Administration, `base' die grundlegenden Pakete, `devel' die Pakete für die Programmierer, `doc' die Dokumentation, `libs' die Programmbibliotheken, `mail' die E-Mail-Leseprogramme und -Dienste, `net' die Netzwerk-Anwendungen und Dienste, die `x11'-Sektion die X11-Programme, die nirgendwo anders unterkommen, usw.

Verändern Sie Sektion also zu x11. (Der Präfix "main/" wird angenommen, wenn Sie nichts angeben, also lassen Sie ihn weg.)

Zeile 3 beschreibt, wie wichtig es für den durchschnittlichen Benutzer wäre, das Paket zu installieren. Lesen Sie das "Policy-Manual" als Anleitung, was Sie in das Feld schreiben. Die Priorität "optional" passt eigentlich bei allen neuen Paketen.

Sektion und Priorität werden zurzeit nur von Programmen wie dselect benutzt, um Pakete zu sortieren und Standardparameter auszuwählen. Wenn Sie das Paket zu Debian hochladen, können (und werden es wahrscheinlich auch) die FTP-Maintainer diesen Wert überschreiben. Sie erhalten dann eine Nachricht darüber per E-Mail.

Da es sich um ein normales Paket handelt und nichts anderes stört, lassen Sie es bei optional.

Zeile 4 ist der Name und die E-Mail-Adresse des Maintainers. Beachten Sie, dass dieses Feld einen gültigen "To:"-Header Eintrag für eine E-Mail enthält, weil nach einem Hochladen zu Debian das Bug Tracking System diesen Eintrag nutzt, um die Bug-E-Mails an Sie zu zustellen. Benutzen Sie keine Kommas, UND-Zeichen und Klammern.

Zeile 5 enthält eine Liste der Pakete, die zum Bauen des Pakets benötigt werden. Einige Pakete wie gcc und make brauchen nicht aufgeführt werden, siehe build-essential Paket für Details. Falls ein unüblicher Compiler oder andere Tools zum Bauen des Pakets benötigt werden, dann sollten Sie diese Pakete zu der Zeile `Build-Depends' hinzufügen. Mehrere Einträge werden durch Komma getrennt; mehr über die Syntax dieses Feldes finden Sie in den Erläuterungen der `binary dependencies'.

An dieser Stelle können weitere Felder wie `Build-Depends-Indep', `Build-Conflicts' u.a. auftreten. Diese werden von der automatischen Paket-Erstellungs-Software in Debian genutzt, um Binär-Pakete für andere Plattformen zu bauen. Lesen Sie im Policy-Manual über Abhängigkeiten beim Paketbauen (build-dependencies) und in der Entwickler-Referenz über andere Plattformen bzw. wie man Software dahin portiert.

Mit diesem Beispiel können Sie herausfinden, welche anderen Pakete Ihr Paket zum Bauen braucht:

     strace -f -o /tmp/log ./configure
     # or make instead of ./configure, if the package doesn't use autoconf
     for x in `dpkg -S $(grep open /tmp/log|\
                         perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\
                         grep "^/"| sort | uniq|\
                         grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\
                         cut -f1 -d":"| sort | uniq`; \
       do \
         echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \
       done

Um die genauen Build-Abhängigkeiten für /usr/bin/foo herauszufinden, führen Sie

     objdump -p /usr/bin/foo | grep NEEDED

und für jede aufgelistete Bibliothek, z.B. libfoo.so.6

     dpkg -S libfoo.so.6

aus. Dann nehmen Sie die Entwickler-Versionen (*-dev) jedes Pakets als einen `Build-deps'-Eintrag. Wenn Sie dafür ldd benutzen, werden auch indirekt abhängende Bibliotheken aufgelistet und überflüssige Build-Abhängigkeiten geliefert.

Gentoo benötigt noch xlibs-dev, libgtk1.2-dev und libglib1.2-dev um gebaut werden zu können, deshalb hängen Sie diese an "debhelper" an.

Zeile 6 enthält die Version des Debian-Policy-Standards, dem dieses Paket entspricht, also die Version, die Sie gelesen haben, während Sie das Paket erstellten.

Zeile 8 enthält die Bezeichnung des Binär-Pakets. Üblicherweise ist sie gleich dem Namen des Quell-Pakets, aber das muss nicht immer so sein.

Zeile 9 beschreibt die CPU-Architektur für die das Binär-Paket kompiliert wird. Wir können das bei "any" belassen, weil es dann von dpkg-gencontrol(1) mit dem richtigen Inhalt ersetzt wird, der für den Rechner gilt, auf dem das Paket gebaut wird.

Wenn ihr Paket unabhängig von der Architektur funktioniert (z.B. ein Shell- oder Perl-Skript, oder Dokumentation), ändern Sie dies zu "all", und lesen Sie später unter Die Datei `rules', Abschnitt 5.4 über die Benutzung der Rule `binary-indep' statt `binary-arch'.

Zeile 10 zeigt eine der mächtigsten Eigenschaften des Paketsystems von Debian. Über spezielle Attribute kann das Verhalten des Paketmanagers in Bezug auf andere Pakete verändert werden. Neben Depends: (Abhängigkeit) gibt es noch weitere Attribute: Recommends: (Empfehlung), Suggests: (Vorschlag), Pre-Depends: (Voraussetzung), Conflicts: (Konflikt), Provides: (Enthält) und Replaces: (Ersetzt).

Die verschiedenen Paketverwaltungs-Programme verhalten sich sehr ähnlich bei der Behandlung dieser Beziehungen (Abweichungen werden weiter unten erklärt). (siehe dpkg(8), dselect(8), apt(8), aptitude(1), usw.)

Und das bedeuten die Abhängigkeiten:

All diese Felder haben eine einheitliche Syntax. Dies ist eine Liste der Paketnamen, getrennt durch Kommas. Ein Paketname kann auch aus einer Liste der alternativen Paketnamen bestehen, die durch senkrechte Striche | ("pipe"-Zeichen) getrennt werden.

Die Angabe des Pakets kann auch auf ganz bestimmte Paketversionen beschränkt werden. Diese Versionen werden in Klammern nach jedem einzelnen Paketnamen aufgeführt und werden durch spezielle Symbole festgelegt, gefolgt von einer Versionsnummer. Folgende Symbole sind erlaubt: <<, <=, =, >= und >> für niedriger, niedriger oder gleich, gleich, höher oder gleich und höher. Zum Beispiel:

     Depends: foo (>= 1.2), libbar1 (= 1.3.4)
     Conflicts: baz
     Recommends: libbaz4 (>> 4.0.7)
     Suggests: quux
     Replaces: quux (<< 5), quux-foo (<= 7.6)

Das letzte Feature, das erwähnt werden sollte, ist die Variable ${shlibs:Depends}. Nachdem Ihr Paket gebaut und in das Unterverzeichnis (A.d.Ü.: debian/tmp) installiert wurde, wird es von dh_shlibdeps(1) nach Binär-Dateien und Bibliotheken durchsucht, um Abhängigkeiten zu `shared libraries' festzustellen und herauszufinden, in welchen Paketen diese stecken, wie z.B. libc6 oder xlib6g. Die Liste wird an dh_gencontrol(1) weiter gegeben um sie an die richtige Stelle zu setzen. Darum brauchen Sie sich nicht zu kümmern.

Wie schon gesagt, Sie lassen die Depends: Zeile wie sie ist und fügen darunter eine neue Zeile Suggests: file, weil gentoo für einige Funktionen dieses Programm/Paket braucht.

Zeile 11 enthält eine Kurzbeschreibung. Bei den meisten Leuten sind die Terminalzeilen 80 Zeichen breit, also sollte die Kurzbeschreibung nicht länger als 60 Zeichen sein. Sie ändern es in "fully GUI configurable X file manager using GTK+".

In die Zeile 12 kommt eine ausführliche Beschreibung des Pakets. Sie sollte aus einem kleinen Text bestehen, der mehr über das Paket verrät. Die erste Spalte der Zeilen sollte immer leer sein. Es dürfen keine leeren Zeilen vorkommen, Sie können aber welche simulieren, indem Sie einen einzelnen . (Punkt) in die Zeile einsetzen. Es darf nach der ausführlichen Beschreibung auch nicht mehr als eine Leerzeile vorkommen.

Und so sieht die angepasste Datei `control' aus:

     1  Source: gentoo
     2  Section: x11
     3  Priority: optional
     4  Maintainer: Josip Rodin <joy-mg@debian.org>
     5  Build-Depends: debhelper(>> 3.0.0),xlibs-dev,libgtk1.2-dev,libglib1.2-dev
     6  Standards-Version: 3.6.1
     7
     8  Package: gentoo
     9  Architecture: any
     10 Depends: ${shlibs:Depends}
     11 Suggests: file
     12 Description: fully GUI configurable X file manager using GTK+
     13  gentoo is a file manager for Linux written from scratch in pure C. It
     14  uses the GTK+ toolkit for all of its interface needs. gentoo provides
     15  100% GUI configurability; no need to edit config files by hand and re-
     16  start the program. gentoo supports identifying the type of various
     17  files (using extension, regular expressions, or the 'file' command),
     18  and can display files of different types with different colors and icons.
     19  .
     20  gentoo borrows some of its look and feel from the classic Amiga file
     21  manager "Directory OPUS" (written by Jonathan Potter).

(Die Zeilennummerierung habe ich für dieses Beispiel hinzugefügt.)


5.2 Die Datei `copyright'

In dieser Datei stehen Informationen über die Herkunft des Pakets (bzw. der Quellen), über die Lizenz und das Urheberrecht (Copyright). Die Policy schreibt keine bestimmte Form vor, aber den benötigten Inhalt (siehe Abschnitt 13.6 "Copyright information").

dh_make erstellt uns eine Standardvorlage, die etwa so aussieht:

     1  This package was debianized by Josip Rodin <joy-mg@debian.org> on
     2  Wed, 11 Nov 1998 21:02:14 +0100.
     3
     4  It was downloaded from <fill in ftp site>
     5
     6  Upstream Author(s): <put author(s) name and email here>
     7
     8  Copyright:
     9
     10 <Must follow here>

(Die Zeilennummerierung habe ich für dieses Beispiel hinzugefügt.)

Die wichtigsten Dinge, die Sie hier einzutragen haben, sind die Quelle, von der Sie das Paket bezogen haben, die geltenden Copyright-Vermerke und die Lizenz. Sie müssen die komplette Lizenz einfügen, sofern es sich nicht um eine der gängigen freien Softwarelizenzen handelt, z.B. die GNU GPL oder LGPL, die BSD- oder die Artistic-License; in diesem Fall reicht ein Verweis auf die entsprechende Datei im Verzeichnis /usr/share/common-licenses/, das auf jedem Debian-System existieren sollte.

Gentoo's Datei `copyright' sollte also so aussehen:

     1  This package was debianized by Josip Rodin <joy-mg@debian.org> on
     2  Wed, 11 Nov 1998 21:02:14 +0100.
     3
     4  It was downloaded from: ftp://ftp.obsession.se/gentoo/
     5
     6  Upstream author: Emil Brink <emil@obsession.se>
     7
     8  This software is copyright (c) 1998-99 by Emil Brink, Obsession
     9  Development.
     10
     11 You are free to distribute this software under the terms of
     12 the GNU General Public License.
     13 On Debian systems, the complete text of the GNU General Public
     14 License can be found in the file `/usr/share/common-licenses/GPL'.

(Die Zeilennummerierung habe ich für dieses Beispiel hinzugefügt.)


5.3 Die Datei `changelog'

Dies ist eine zwingend vorgeschriebene Datei, deren Format in der Policy Sektion 4.4 "debian/changelog" beschrieben wird. Dieses Format benötigen dpkg und andere Programme um Dinge wie Versionsnummer, Revision, Distribution und die Wichtigkeit ihres Pakets zu bestimmen.

Für Sie ist die Datei ebenfalls wichtig, weil man hier die gemachten Änderungen dokumentieren kann. Damit können Leute, die Ihr Paket herunterladen, einfacher herausfinden, ob es Probleme mit dem Paket gibt, die sie kennen sollten. Diese Datei wird im Binär-Paket als /usr/share/doc/gentoo/changelog.Debian.gz gespeichert.

dh_make erstellt eine Standardvorlage, die etwa so aussieht:

     1  gentoo (0.9.12-1) unstable; urgency=low
     2
     3   * Initial Release.
     4
     5  -- Josip Rodin <joy-mg@debian.org> Wed, 11 Nov 1998 21:02:14 +0100
     6

(Die Zeilennummerierung habe ich für dieses Beispiel hinzugefügt.)

In der Zeile 1 stehen der Paketname, die Version, die Distribution und die Wichtigkeit. Der Name muss mit dem Namen des Quell-Pakets übereinstimmen, Distribution sollte vorerst `unstable' (oder sogar `experimental') sein und die Priorität nicht höher als `low'. :-)

Zeilen 3-5 sind Log-Einträge, in den Sie die in dieser Revision gemachten Änderungen dokumentieren können. (Hierher kommt nichts über die Änderungen des Upstream-Maintainers, für diese Zwecke gibt es eine separate Datei, die Sie später als /usr/share/doc/gentoo/changelog.gz speichern werden.) Neue Zeilen werden direkt über die oberste Zeile, die mit einem Stern (`*') beginnt, eingefügt. Sie können das mit dch(1), oder per Hand mit einem Texteditor erledigen.

Schließlich kommen Sie zu einer Datei wie dieser hier:

     1  gentoo (0.9.12-1) unstable; urgency=low
     2
     3   * Initial Release.
     4   * This is my first Debian package.
     5   * Adjusted the Makefile to fix $DESTDIR problems.
     6
     7  -- Josip Rodin <joy-mg@debian.org> Wed, 11 Nov 1998 21:02:14 +0100
     8

(Die Zeilennummerierung habe ich für dieses Beispiel hinzugefügt.)

Mehr über Änderungen in der Datei `changelog' können Sie später in Weiterentwicklung des Pakets, Kapitel 10 lesen.


5.4 Die Datei `rules'

Nun müssen Sie einen Blick auf die eigentlichen Befehlssequenzen, sog. Rules, werfen, mit denen dpkg-buildpackage(1) das Paket schließlich erstellt. Die Datei `rules' ist im Prinzip ein weiteres Makefile, unterscheidet sich aber von denen des Upstream-Autors. Im Gegensatz zu anderen Dateien in debian/ ist diese Datei ausführbar.

Wie jedes andere Makefile besteht die Datei `rules' aus mehreren Rules, die bestimmen, wie mit dem Quellcode verfahren wird. Jede Rule besteht wiederum aus weiteren Targets, Dateinamen oder Namen der Aktionen, die durchgeführt werden (z.B. `build:' oder `install:'). Rules, die Sie ausführen möchten, werden beim Aufruf als Programmparameter angegeben (z.B., `./debian/rules build` oder `make -f rules install`). Nach dem Targetnamen (A.d.Ü.: nach der Bezeichnung unserer Rule) können Sie Programme oder Dateinamen angeben, von der die Ausführung der Rule abhängt. Danach folgt eine beliebige Anzahl von Kommandos, eingerückt mit <tab>. Eine neue Rule beginnt mit der Deklaration eines Targets in der ersten Spalte. Leerzeilen und mit einem `#' (hash) beginnende Zeilen werden als Kommentare betrachtet und ignoriert.

Sie sind vielleicht etwas verwirrt, aber es wird alles verständlich nach der genaueren Betrachtung der Datei `rules', die uns dh_make erstellt hat. Sie sollten evtl. die Info-Seiten von make lesen, um mehr über die Funktionsweise zu erfahren.

Wichtig zu wissen ist noch, dass dh_make nur ein Muster der Datei `rules' erzeugt, also einen Vorschlag, wie sie ungefähr auszusehen hat. Diese Datei wird für einfache Pakete wahrscheinlich funktionieren, aber bei komplizierteren sollten Sie die Datei nach Bedarf anpassen und erweitern. Sie dürfen nur die Namen der Rules nicht ändern, weil diese in der Policy vorgeschrieben sind und von allen Programmen (für die Paketerstellung) so erwartet werden.

     1  #!/usr/bin/make -f
     2  # Sample debian/rules that uses debhelper.
     3  # GNU copyright 1997 to 1999 by Joey Hess.
     4
     5  # Uncomment this to turn on verbose mode.
     6  #export DH_VERBOSE=1
     7
     8  # This is the debhelper compatibility version to use.
     9  export DH_COMPAT=4
     10
     11 CFLAGS = -g
     12 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
     13 CFLAGS += -O0
     14 else
     15 CFLAGS += -O2
     16 endif
     17
     18 build: build-stamp
     19 build-stamp:
     20        dh_testdir
     21
     22        # Add here commands to compile the package.
     23        $(MAKE)
     24        #docbook-to-man debian/gentoo.sgml > gentoo.1
     25
     26        touch build-stamp
     27
     28 clean:
     29        dh_testdir
     30        dh_testroot
     31        rm -f build-stamp
     32
     33        # Add here commands to clean up after the build process.
     34        -$(MAKE) clean
     35
     36        dh_clean
     37
     38 install: build
     39        dh_testdir
     40        dh_testroot
     41        dh_clean -k
     42        dh_installdirs
     43
     44        # Add here commands to install the package into debian/gentoo.
     45        $(MAKE) install DESTDIR=$(CURDIR)/debian/gentoo
     46
     47 # Build architecture-independent files here.
     48 binary-indep: build install
     49 # We have nothing to do by default.
     50
     51 # Build architecture-dependent files here.
     52 binary-arch: build install
     53        dh_testdir
     54        dh_testroot
     55 #      dh_installdebconf
     56        dh_installdocs
     57        dh_installexamples
     58        dh_installmenu
     59 #      dh_installlogrotate
     60 #      dh_installemacsen
     61 #      dh_installpam
     62 #      dh_installmime
     63 #      dh_installinit
     64        dh_installcron
     65        dh_installman
     66        dh_installinfo
     67 #      dh_undocumented
     68        dh_installchangelogs ChangeLog
     69        dh_link
     70        dh_strip
     71        dh_compress
     72        dh_fixperms
     73 #      dh_makeshlibs
     74        dh_installdeb
     75 #      dh_perl
     76        dh_shlibdeps
     77        dh_gencontrol
     78        dh_md5sums
     79        dh_builddeb
     80
     81 binary: binary-indep binary-arch
     82 .PHONY: build clean binary-indep binary-arch binary install

(Zeilennummerierung habe ich für dieses Beispiel hinzugefügt. In der richtigen Datei debian/rules sind die führenden Leerzeichen ein TAB.)

Die Funktion der ersten Zeile kennen Sie vielleicht von Perl- oder Shell-Skripten. Sie teilt dem Betriebssystem mit, dass das Skript mit /usr/bin/make interpretiert wird.

Die Zeilen 6 bis 9 enthalten Variablen DH_*, deren Bedeutung durch die Kurzbeschreibung klar werden sollte. Mehr Informationen über DH_COMPAT finden Sie in dem Kapitel "Debhelper compatibility levels" in der Manpage debhelper(1).

Die Zeilen 11 bis 16 beinhalten ein Grundgerüst für die Auswertung der Parameter in DEB_BUILD_OPTIONS, die in der Policy, Kapitel 11.1 "Binaries" beschrieben sind. Im Grunde steuern Sie hier, ob die Binär-Dateien mit Debugging-Informationen gebaut werden und ob diese während der Installation wieder entfernt werden sollen. Nochmal, es ist ein Grundgerüst, ein Hinweis, dass Sie so vorgehen können. Sie müssen herausfinden, wie das Einfügen und Entfernen von Debugging-Informationen im Upstream-Quellcode gehandhabt wird und es selbst einbauen.

Normalerweise sollten Sie die Variable CFLAGS benutzen, um gcc mit der Option "-g" aufzurufen. Wenn Sie das tun, dann sollten Sie die Variable mittels CFLAGS="$(CFLAGS)" an den Aufruf $(MAKE) in der Rule `build' anhängen (siehe unten). Wenn Ihr Paket aber ein autoconf-Skript verwendet, können Sie die Variable an `configure' übergeben, indem Sie die o. g. Zeichenkette dem Aufruf `./configure` in der Rule `build' voranstellen.

Weil Sie gerade beim "stripping" sind. :-) Häufig sind Programme so konfiguriert, dass sie ungestrippt installiert werden, oft ohne eine Möglichkeit, das zu ändern. Zum Glück haben Sie dh_strip(1), das das Flag DEB_BUILD_OPTIONS=nostrip erkennt und still endet.

Zeilen 18 bis 26 enthalten die Rule `build' (und die untergeordnete `build-stamp'-Rule), die mit dem Makefile der Anwendung das Programm kompiliert. Wenn Ihr Paket die "GNU configure"-Werkzeuge benutzt, sollten Sie unbedingt /usr/share/doc/autotools-dev/README.Debian.gz gelesen haben. Auf die auskommentierte Zeile der docbook-to-man Umwandlung wird später in manpage.1.ex, manpage.sgml.ex, Abschnitt 6.8 eingegangen.

Die Rule `clean' in den Zeilen 28-36 entsorgt alle unnötigen Binär- und automatisch generierten Dateien, die nach der Paketerstellung zurückbleiben. Diese Rule muss jederzeit funktionsfähig sein, auch wenn im Quellcode-Verzeichnis bereits aufgeräumt wurde, also sollten Sie evtl. die "Zwang"-Optionen benutzen (z.B. "-f" bei rm), oder die Rückgabewerte (Fehler) mit einem `-' am Anfang des Befehls ignorieren.

Der Installationsprozess, die Rule `install', beginnt in der Zeile 38. Es wird einfach die Rule `install' des programmeigenen Makefiles ausgeführt, aber in das Verzeichnis $(CURDIR)/debian/gentoo installiert - aus diesem Grund haben Sie in gentoo's Makefile auch die Variable $(DESTDIR) (als Root-Verzeichnis der Installation) eingebaut.

Die Rule `binary-indep' in der Zeile 48, ist, wie der Kommentar bereits sagt, für die Erstellung von architekturunabhängigen Paketen vorgesehen. Das ist bei Ihrem Paket nicht der Fall, also wird hier auch nichts gemacht.

Auf zur nächsten Rule - `binary-arch' in den Zeilen 52 bis 79, in der verschiedene kleine Hilfsprogramme aus dem Paket dephelper gestartet werden, die an unseren Dateien verschiedene Operationen durchführen, um das Paket an die Policy anzupassen.

Wenn Ihr Paket `Architecture: all' entspricht, dann müssen Sie alle Kommandos zum Bauen des Pakets in der Rule `binary-indep' platzieren und die Rule `binary-arch' dafür leer lassen.

Die Namen der debhelper-Programme beginnen mit dh_ und der Rest erklärt bereits die Aufgabe des Tools. Alles ist praktisch selbsterklärend, hier dennoch einige zusätzlichen Erläuterungen:

Die vollständigen Infos über die Aufgaben und Bedienung all dieser dh_*-Skripte finden Sie in den jeweiligen Manpages. Es gibt noch weitere (möglicherweise sehr nützliche) dh_*-Skripte, die hier nicht weiter erwähnt werden. Wenn Sie die mal brauchen, lesen Sie die Debhelper-Dokumentation.

Die Sektion "binary-arch" ist eine, in der Sie wirklich alle Zeilen, in den nicht benötigte Features installiert werden, auskommentieren oder entfernen sollten. Bei Gentoo kommentieren Sie Zeilen mit folgenden Befehlen aus, weil Gentoo diese nicht braucht: examples, cron, init, man und info. In der Zeile 68 werden Sie `ChangeLog' durch `FIXES' ersetzen, weil das der Name der Changelog-Datei des Upstreams ist.

Die letzten zwei Zeilen sind (genau wie andere, nicht weiter erklärte Zeilen) mehr oder weniger benötigte Dinge, über die Sie mehr im make-Manual oder der Policy nachlesen können. Im Moment brauchen Sie darüber nichts zu wissen.


[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ weiter ]

Anleitung für zukünftige Debian-Maintainer

Version 1.2.3, 18. Januar 2005.

Josip Rodin joy-mg@debian.org
Übersetzer: Erik Schanze mail@erikschanze.de
Übersetzer: Eduard Bloch blade@debian.org