[ 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 12.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  # -*- makefile -*-
          3  # Sample debian/rules that uses debhelper.
          4  # This file was originally written by Joey Hess and Craig Small.
          5  # As a special exception, when this file is copied by dh-make into a
          6  # dh-make output file, you may use that output file without restriction.
          7  # This special exception was added by Craig Small in version 0.37 of dh-make.
          8  # Uncomment this to turn on verbose mode.
          9  #export DH_VERBOSE=1
         10  configure: configure-stamp
         11  configure-stamp:
         12          dh_testdir
         13          # Add here commands to configure the package.
         14          touch configure-stamp
         15  build: build-stamp
         16  build-stamp: configure-stamp  
         17          dh_testdir
         18          # Add here commands to compile the package.
         19          $(MAKE)
         20          #docbook-to-man debian/testpack.sgml > testpack.1
         21          touch $@
         22  clean: 
         23          dh_testdir
         24          dh_testroot
         25          rm -f build-stamp configure-stamp
         26          # Add here commands to clean up after the build process.
         27          $(MAKE) clean
         28          dh_clean 
         29  install: build
         30          dh_testdir
         31          dh_testroot
         32          dh_clean -k 
         33          dh_installdirs
         34          # Add here commands to install the package into debian/testpack.
         35          $(MAKE) DESTDIR=$(CURDIR)/debian/testpack install
         36  # Build architecture-independent files here.
         37  binary-indep: build install
         38  # We have nothing to do by default.
         39  # Build architecture-dependent files here.
         40  binary-arch: build install
         41          dh_testdir
         42          dh_testroot
         43          dh_installchangelogs 
         44          dh_installdocs
         45          dh_installexamples
         46  #       dh_install
         47  #       dh_installmenu
         48  #       dh_installdebconf       
         49  #       dh_installlogrotate
         50  #       dh_installemacsen
         51  #       dh_installpam
         52  #       dh_installmime
         53  #       dh_python
         54  #       dh_installinit
         55  #       dh_installcron
         56  #       dh_installinfo
         57          dh_installman
         58          dh_link
         59          dh_strip
         60          dh_compress
         61          dh_fixperms
         62  #       dh_perl
         63  #       dh_makeshlibs
         64          dh_installdeb
         65          dh_shlibdeps
         66          dh_gencontrol
         67          dh_md5sums
         68          dh_builddeb
         69  binary: binary-indep binary-arch
         70  .PHONY: build clean binary-indep binary-arch binary install configure

(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 8 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 10.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