[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
debian
directory
There is a new subdirectory under the program's source directory, it's called
debian
. There are a number of files in this directory that we
should edit in order to customize the behavior of the package. The most
important of them are control
, changelog
,
copyright
and rules
, which are required for all
packages.
control
file
This file contains various values which dpkg
,
dselect
, apt-get
, apt-cache
,
aptitude
, and other package management tools will use to manage
the package. It is defined by the Debian
Policy Manual, 5 'Control files and their fields'
.
Here is the control file dh_make
created for us:
1 Source: gentoo 2 Section: unknown 3 Priority: extra 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper (>= 7.0.50~) 6 Standards-Version: 3.8.4 7 Homepage: <insert the upstream URL, if relevant> 8 9 Package: gentoo 10 Architecture: any 11 Depends: ${shlibs:Depends}, ${misc:Depends} 12 Description: <insert up to 60 chars description> 13 <insert long description, indented with spaces>
(I've added the line numbers.)
Lines 1-6 are the control information for the source package.
Line 1 is the name of the source package.
Line 2 is the section of the distribution the source package goes into.
As you may have noticed, Debian archive is divided in sections:
main (the free software), non-free (the not really
free software) and contrib (free software that depends on non-free
software). Under those, there are logical subsections that describe in short
what packages are in. So we have admin for administrator-only
programs, base for the basic tools, devel for
programmer tools, doc for documentation, libs for
libraries, mail for e-mail readers and daemons, net
for network apps and daemons, x11 for X11 programs that don't fit
anywhere else, and many more. See the Debian
Policy Manual, 2.4 'Sections'
and List of sections in
'sid'
for the guidance.
Let's change it then to x11. (A main/ prefix is implied so we can omit it.)
Line 3 describes how important it is that the user installs this package. See
the Debian
Policy Manual, 2.5 'Priorities'
for the guidance.
The optional priority will usually work for new packages that do not conflict with others with required, important or standard priorities.
The extra priority will usually work for new packages that conflict with others with non-extra priorities.
Section and priority are used by the frontends like aptitude
when
they sort packages and select defaults. Once you upload the package to Debian,
the value of these two fields can be overridden by the archive maintainers, in
which case you will be notified by email.
As this is a normal priority package and doesn't conflict with anything else, we will change the priority to "optional".
Line 4 is the name and email address of the maintainer. Make sure that this field includes a valid "To" header for an email, because after you upload it, the bug tracking system will use it to deliver bug emails to you. Avoid using commas, ampersands and parenthesis.
The 5th line includes the list of packages required to build your package as
the Build-Depends field. You can also have the
Build-Depends-Indep field as an additional line, here. (see the
Debian
Policy Manual, 7.7 'Relationships between source and binary packages -
Build-Depends, Build-Depends-Indep, Build-Conflicts,
Build-Conflicts-Indep'
). Some packages like gcc
and
make
which are required by the build-essential
package are implied. If you need to have other tools to build your package,
you should add them to these fields. Multiple entries are separated with
commas; read on for the explanation of binary dependencies to find out more
about the syntax of these lines.
For all packages packaged with the dh
command in the
debian/rules
file, you must have "debhelper
(>=7.0.50~)" in the Build-Depends field to satisfy
the Debian Policy requirement for the clean target.
For source packages which have some binary packages with "Architecture: any", they are rebuild by the autobuilder. Since this autobuilder procedure runs "debian/rules build" in it while installing only packages listed in the Build-Depends field (see Autobuilder, Section 6.2), the Build-Depends field needs to list practically all the required packages and the Build-Depends-indep is rarely used.
For source packages which have binary packages only with "Architecture: all", the Build-Depends-Indep field may list all the required packages unless they are already listed in the Build-Depends field to satisfy the Debian Policy requirement for the clean target.
If you are not sure which one should be used, use the Build-Depends field to be on the safe side. [16]
To find out what packages your package needs to be built run the command:
$ dpkg-depcheck -d ./configure
To manually find exact build dependency for
/usr/bin/foo
, you execute
$ objdump -p /usr/bin/foo | grep NEEDED
and for each library listed, e.g., libfoo.so.6
, execute
$ dpkg -S libfoo.so.6
Then you just take -dev version of every package as
Build-Depends entry. If you use ldd
for this
purpose, it will report indirect lib dependencies as well, resulting in the
problem of excessive build dependencies.
gentoo
also happens to require xlibs-dev
,
libgtk1.2-dev
and libglib1.2-dev
to build, so we'll
add them here next to debhelper
.
Line 6 is the version of the Debian Policy
Manual
standards this package follows, the one you read while making
your package.
On line 7 you can put the URL of the homepage for the upstream program.
Line 9 is the name of the binary package. This is usually the same as the name of the source package, but it doesn't necessarily have to be that way.
Line 10 describes the CPU architecture the binary package can be compiled for.
We'll leave this as "any" because
dpkg-gencontrol(1)
will fill in the appropriate value for any
machine this package gets compiled on.
If your package is architecture independent (for example, a shell or Perl
script, or a document), change this to "all", and read
later in rules
file, Section 4.4 about
using the binary-indep rule instead of binary-arch
for building the package.
Line 11 shows one of the most powerful features of the Debian packaging system. Packages can relate to each other in various ways. Apart from Depends, other relationship fields are Recommends, Suggests, Pre-Depends, Breaks, Conflicts, Provides, and Replaces.
The package management tools usually behave the same way when dealing with
these relations; if not, it will be explained. (see dpkg(8)
,
dselect(8)
, apt(8)
, aptitude(1)
etc.)
This is what the dependencies mean:
Depends
The package will not be installed unless the packages it depends on are installed. Use this if your program absolutely will not run (or will cause severe breakage) unless a particular package is present.
Recommends
Use this for packages that are not strictly necessary but are typically used
with your program. When a user installs your program, all frontends will
likely prompt them to install the recommended packages. aptitude
and apt-get
install recommended packages along with your package
(but the user can disable this default behaviour). dpkg
will
ignore this field.
Suggests
Use this for packages which will work nicely with your program but are not at
all necessary. When a user installs your program, all frontends will likely
prompt them to install the suggested packages. aptitude
can be
configured to install suggested packages along with your package but this is
not its default. dpkg
and apt-get
will ignore this
field.
Pre-Depends
This is stronger than Depends. The package will not be installed
unless the packages it pre-depends on are installed and correctly
configured. Use this very sparingly and only after discussing it
on the debian-devel@lists.debian.org
mailing list. Read: don't use it at all. :-)
Conflicts
The package will not be installed until all the packages it conflicts with have been removed. Use this if your program absolutely will not run or will cause severe problems if a particular package is present.
Breaks
The package will be installed while all the listed packages will be broken. Normally a Breaks entry has an "earlier than" version clause. The resolution is generally to upgrade the listed packages by the higher-level package management tools.
Provides
For some types of packages where there are multiple alternatives virtual names
have been defined. You can get the full list in the
/usr/share/doc/debian-policy/virtual-package-names-list.txt.gz
file. Use this if your program provides a function of an existing virtual
package.
Replaces
Use this when your program replaces files from another package, or completely replaces another package (used in conjunction with Conflicts). Files from the named packages will be overwritten with the files from your package.
All these fields have uniform syntax. They are a list of package names separated by commas. These package names may also be lists of alternative package names, separated by vertical bar symbols "|" (pipe symbols).
The fields may restrict their applicability to particular versions of each named package. These versions are listed in parentheses after each individual package name, and they should contain a relation from the list below followed by the version number. The relations allowed are: <<, <=, =, >= and >> for strictly lower, lower or equal, exactly equal, greater or equal and strictly greater, respectively. For example,
Depends: foo (>= 1.2), libbar1 (= 1.3.4) Conflicts: baz Recommends: libbaz4 (>> 4.0.7) Suggests: quux Replaces: quux (<< 5), quux-foo (<= 7.6)
The last feature you need to know about is ${shlibs:Depends},
${perl:Depends}, ${misc:Depends}, etc. These entries
are substituted by the list generated by other debhelper
components when the dh_gencontrol(1)
command is executed.
dh_shlibdeps(1)
will scan it for binaries and libraries determine
their shared library dependencies and detect which packages they are in, such
as libc6
or xlib6g
, after your package has been built
and installed into the temporary directory. This list of shared library
dependencies is used for ${shlibs:Depends}.
The package list generated by the dh_perl(1)
is used for
${perl:Depends}.
Some debhelper
commands may make the generated package need to
depend on some other packages. This list of required packages is used for
${misc:Depends}.
Having said all that, we can leave the Depends field exactly as it
is now, and insert another line after it saying "Suggests:
file", because gentoo
can use some features provided
by that file
package.
Line 12 is the short description. Most people screens are 80 columns wide so this shouldn't be longer than about 60 characters. I'll change it to "fully GUI-configurable, two-pane X file manager".
Line 13 is where the long description goes. This should be a paragraph which gives more details about the package. Column 1 of each line should be empty. There must be no blank lines, but you can put a single "." (dot) in a column to simulate that. Also, there must be no more than one blank line after the long description.
Let's insert Vcs-* fields documented in Developer's
Reference, 6.2.5. 'Version Control System location'
between line 6
and 7. Let's assume that the gentoo
package is located in Debian
Alioth Git Service at
git://git.debian.org/git/collab-maint/gentoo.git.
Finally, here is the updated control
file:
1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper (>= 7.0.5), xlibs-dev, libgtk1.2-dev, libglib1.2-dev 6 Standards-Version: 3.8.4 7 Vcs-Git: git://git.debian.org/git/collab-maint/gentoo.git 8 Vcs-browser: http://git.debian.org/?p=collab-maint/gentoo.git 9 Homepage: http://www.obsession.se/gentoo/ 10 11 Package: gentoo 12 Architecture: any 13 Depends: ${shlibs:Depends}, ${misc:Depends} 14 Suggests: file 15 Description: fully GUI-configurable, two-pane X file manager 16 gentoo is a two-pane file manager for the X Window System. gentoo lets the 17 user do (almost) all of the configuration and customizing from within the 18 program itself. If you still prefer to hand-edit configuration files, 19 they're fairly easy to work with since they are written in an XML format. 20 . 21 gentoo features a fairly complex and powerful file identification system, 22 coupled to a object-oriented style system, which together give you a lot 23 of control over how files of different types are displayed and acted upon. 24 Additionally, over a hundred pixmap images are available for use in file 25 type descriptions. 26 . 29 gentoo was written from scratch in ANSI C, and it utilises the GTK+ toolkit 30 for its interface.
(I've added the line numbers.)
copyright
file
This file contains the information about package upstream resources, copyright
and license information. Its format is not dictated by the Debian Policy
Manual, but the content is (Debian
Policy Manual, 12.5 'Copyright information'
). You may also consult
DEP-5: Machine-parseable
debian/copyright
.
dh_make
can give you a template copyright
file.
Let's use the "--copyright gpl2" option here to get a
template file for the gentoo
package released under GPL-2.
You must fill in missing information such as the place you got the package
from, the actual copyright notice and their license to complete this file. For
the common free software licenses such as GNU GPL-1, GNU GPL-2, GNU GPL-3,
LGPL-2, LGPL-2.1, LGPL-3, GNU FDL-1.2, GNU FDL-1.3, Apache-2.0 or the Artistic
license, you can just refer to the appropriate file in
/usr/share/common-licenses/
directory that exists on every Debian
system. Otherwise, you must include the complete license.
In short, here's how gentoo
's copyright
file should
look like:
1 Format-Specification: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135 2 Name: gentoo 3 Maintainer: Josip Rodin <joy-mg@debian.org> 4 Source: http://sourceforge.net/projects/gentoo/files/ 5 6 Copyright: 1998-2010 Emil Brink <emil@obsession.se> 7 License: GPL-2+ 8 9 Files: icons/* 10 Copyright: 1998 Johan Hanson <johan@tiq.com> 11 License: GPL-2+ 12 13 Files: debian/* 14 Copyright: 1998-2010 Josip Rodin <joy-mg@debian.org> 15 License: GPL-2+ 16 17 License: GPL-2+ 18 This program is free software; you can redistribute it and/or modify 19 it under the terms of the GNU General Public License as published by 20 the Free Software Foundation; either version 2 of the License, or 21 (at your option) any later version. 22 . 23 This program is distributed in the hope that it will be useful, 24 but WITHOUT ANY WARRANTY; without even the implied warranty of 25 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 26 GNU General Public License for more details. 27 . 28 You should have received a copy of the GNU General Public License along 29 with this program; if not, write to the Free Software Foundation, Inc., 30 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. 31 . 32 On Debian systems, the full text of the GNU General Public 33 License version 2 can be found in the file 34 `/usr/share/common-licenses/GPL-2'.
(I've added the line numbers.)
Please follow the HOWTO provided by ftpmasters and sent to
debian-devel-announce: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
.
changelog
file
This is a required file, which has a special format described in the Debian
Policy Manual, 4.4 'debian/changelog'
. This format is used by
dpkg
and other programs to obtain the version number, revision,
distribution and urgency of your package.
For you, it is also important, since it is good to have documented all changes
you have done. It will help people downloading your package to see whether
there are issues with the package that they should know about. It will be
saved as /usr/share/doc/gentoo/changelog.Debian.gz
in the binary
package.
dh_make
created a default one, and this is how it looks like:
1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial release (Closes: #nnnn) <nnnn is the bug number of your ITP> 4 5 -- Josip Rodin <joy-mg@debian.org> Mon, 22 Mar 2010 00:37:31 +0100 6
(I've added the line numbers.)
Line 1 is the package name, version, distribution, and urgency. The name must match the source package name, distribution should be either unstable (or even experimental) [17], and urgency shouldn't be changed to anything higher than low. :-)
Lines 3-5 are a log entry, where you document changes made in this package
revision (not the upstream changes - there is special file for that purpose,
created by the upstream authors, which you will later install as
/usr/share/doc/gentoo/changelog.gz
). Let's assume your ITP
(Intent To Package) bug report number was "12345". New
lines must be inserted just before the uppermost line that begins with
"*" (asterisk). You can do it with dch(1)
,
or manually with a text editor.
You will end up with something like this:
1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. Closes: #12345 4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $(DESTDIR) problems. 6 7 -- Josip Rodin <joy-mg@debian.org> Mon, 22 Mar 2010 00:37:31 +0100 8
(I've added the line numbers.)
You can read more about updating the changelog
file later in Updating the package, Chapter 9.
rules
file
Now we need to take a look at the exact rules which
dpkg-buildpackage(1)
will use to actually create the package.
This file is actually another Makefile
, but different from the
one(s) in the upstream source. Unlike other files in debian
, this
one is marked as executable.
rules
file
Every rules
file, as any other Makefile
, consists of
several targets and their rules specifying how to handle the source. Debian
Policy Manual, 4.9 'Main building script: debian/rules'
explains its
details.
The simplified explanation of targets are the following.
clean target: to clean all compiled, generated, and useless files in the build-tree. (required)
build target: to build the source into compiled programs and formatted documents in the build-tree. (required)
install target: to install files into a file tree for each binary
package under the debian
directory. If defined,
binary* targets effectively depend on this target. (optional)
binary target: to create all binary packages (effectively combination of binary-arch and binary-indep targets). (required)[18]
binary-arch target: to create arch-dependent (Architecture: any) binary packages in the parent directory. (required)[19]
binary-indep target: to create arch-independent (Architecture: all) binary packages in the parent directory. (required)[20]
get-orig-source target: to obtain the most recent version of the original source package from upstream archive site. (optional)
Rules that you want to execute are invoked as command line arguments (for example, "./debian/rules build" or "fakeroot make -f debian/rules binary"). After the target name, you can name the dependency, program or file that the rule depends on. After that, there can be any number of commands, indented with TAB. A new rule begins with the target declaration in the first column. Empty lines and lines beginning with "#" (hash) are treated as comments and ignored.
You are probably confused now, but it will all be clear upon examination of the
rules
file that dh_make
gives us as a default. You
should also read "info make" for more information.
rules
file
Newer dh_make
generates a very simple but powerful default
rules
file using the dh
command:
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 9 # Uncomment this to turn on verbose mode. 10 #export DH_VERBOSE=1 11 12 %: 13 dh $@
(I've added the line numbers. In the actual rules
file, the
leading white spaces are TAB codes.)
You are probably familiar with lines like line 1 from shell and Perl scripts.
It tells the operating system that this file is to be processed with
/usr/bin/make
.
Line 10 can be uncommented to set DH_VERBOSE variable to 1. Then,
the dh
command will output which dh_*
commands are
executed by the dh
command. You can also add "export
DH_OPTIONS=-v" line here. Then each dh_*
command will
output which commands are executed by each dh_*
command. This
helps you to understand what exactly is going on behind this simple
rules
file and to debug its problems. This new dh
is
a core part of the debhelper
tools and does not hide anything from
you.
Lines 12 and 13 are where all the work is done. The percent sign means any
targets which then call a single program, dh
with the target name.
[21] The dh
command is a wrapper script which runs appropriate sequences of
dh_*
programs depending on its argument. [22]
"debian/rules clean" runs "dh clean"; which in turn runs the following:
dh_testdir dh_auto_clean dh_clean
"debian/rules build" runs "dh build"; which in turn runs the following:
dh_testdir dh_auto_configure dh_auto_build dh_auto_test
"fakeroot debian/rules binary" runs "fakeroot dh binary"; which in turn runs the following[23]:
dh_testroot dh_prep dh_installdirs dh_auto_install dh_install dh_installdocs dh_installchangelogs dh_installexamples dh_installman dh_installcatalogs dh_installcron dh_installdebconf dh_installemacsen dh_installifupdown dh_installinfo dh_pysupport dh_installinit dh_installmenu dh_installmime dh_installmodules dh_installlogcheck dh_installlogrotate dh_installpam dh_installppp dh_installudev dh_installwm dh_installxfonts dh_bugfiles dh_lintian dh_gconf dh_icons dh_perl dh_usrlocal dh_link dh_compress dh_fixperms dh_strip dh_makeshlibs dh_shlibdeps dh_installdeb dh_gencontrol dh_md5sums dh_builddeb
"fakeroot debian/rules binary-arch" runs "fakeroot dh binary-arch"; which in turn runs the same sequence as "fakeroot dh binary" but with the "-a" option appended for each command.
"fakeroot debian/rules binary-indep" runs
"fakeroot dh binary-indep"; which in turn runs almost
the same sequence as "fakeroot dh binary" but excluding
dh_strip
, dh_makeshlibs
, and
dh_shlibdeps
with the "-i" option appended
for each remaining command.
The function of dh_*
commands are almost self-evident from their
names. [24] There are few
notable ones worth making (over)simplified explanation here assuming typical
build environment based on Makefile
. [25]
dh_auto_clean
usually executes the following if
Makefile
exists with the distclean target. [26]
make distclean
dh_auto_configure
usually executes the following if
./configure
exists (arguments abbreviated for readability).
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var ...
dh_auto_build
usually executes the following to execute the first
target of Makefile
if it exists.
make
dh_auto_test
usually executes the following if
Makefile
exists with the test target. [27]
make test
dh_auto_install
usually executes the following if
Makefile
exists with the install target (line folded
for readability).
make install \ DESTDIR=/path/to/package_version-revision/debian/package
Targets which require the fakeroot
command contain
dh_testroot
. If you are not pretending to be root using this
command, it exits with an error.
The important part to know about the rules
file created by
dh_make
, is that it is just a suggestion. It will work for most
packages but for more complicated ones, don't be afraid to customize it to fit
your needs. Only things that you must not change are the names of the rules,
because all the tools use these names, as mandated by the Debian Policy.
Although "install" is not required target, it is
supported. "fakeroot dh install" behaves like
"fakeroot dh binary" but stops after
dh_fixperms
.
rules
file
There are many ways to customize the rules
file created with the
new dh
command.
The "dh $@" command can be customized as follows. [28]
Add support of the dh_pysupport
command. (The best choice for
Python.) [29]
Install the python-support
package in
"Build-Depends".
Use "dh $@" as usual. (This is enabled by default)
This handles Python modules using the python-support
framework.
Add support of the dh_pycentral
command.
Install the python-central
package in
"Build-Depends".
Use "dh --with python-central $@" instead.
This also deactivates the dh_pysupport
command.
This handles Python modules using the python-central
framework.
Add support of the dh_installtex
command.
Install the tex-common
package in
"Build-Depends".
Use "dh --with tex $@" instead.
This registers Type 1 fonts, hyphenation patterns, or formats with TeX.
Add support of the dh_quilt_patch
and
dh_quilt_unpatch
commands.
Install the quilt
package in
"Build-Depends".
Use "dh --with quilt $@" instead.
This applies and un-applies patches to the upstream source from files in the
debian/patches
directory for the 1.0 source package.
This is not needed if you use the new 3.0 (quilt) source package.
Add support of the dh_dkms
command.
Install the dkms
package in
"Build-Depends".
Use "dh --with dkms $@" instead.
This correctly handles DKMS usage by the kernel module package.
Add support of the dh_autotools-dev_updateconfig
and
dh_autotools-dev_restoreconfig
commands.
Install the autotools-dev
package in
"Build-Depends".
Use "dh --with autotools-dev $@" instead.
This updates and restores config.sub
and
config.guess
.
Add support of the dh_autoreconf
and
dh_autoreconf_clean
commands.
Install the dh-autoreconf
package in
"Build-Depends".
Use "dh --with autoreconf $@" instead.
This updates the GNU Build System files and restores them after the build.
Add support to the bash
completion feature.
Install the bash-completion
package in
"Build-Depends".
Use "dh --with bash-completion $@" instead.
This installs bash
completions using configuration file at
debian/package.bash-completion
.
For sources using Autotools, use combination of above as "dh --with autotools-dev --with autoreconf $@" to be most current with the GNU Build System.
Many dh_*
commands invoked by the new dh
command can
be customized by the corresponding configuration files in the
debian
directory. See Other files
under the debian
directory, Chapter 5 and the manpage of each
command for the customization of such features.
Some dh_*
commands invoked by the new dh
command may
require you to run it with some arguments or to run additional commands with
them or to skip them. For such cases, you create an
override_dh_foo target with its rule in the
rules
file only for the dh_foo
command you
want to change. It basically say "run me instead". [30]
Please note that the dh_auto_*
commands tend to do more than what
has been discussed as (over)simplified explanation to take care all the corner
cases. Use of simplified equivalent command instead of these in
override_dh_* targets except the
override_dh_auto_clean target is a bad idea since it may kill such
debhelper
's smart features.
If you want to store the system configuration data for the gentoo
package in the /etc/gentoo
directory instead of the usual
/etc
directory, you can override the default
--sysconfig=/etc argument given by the
dh_auto_configure
command to the ./configure
command
by the following. [31]
override_dh_auto_configure: dh_auto_configure -- --sysconfig=/etc/gentoo
The arguments given after -- are appended to the default arguments
of the auto-executed program to override them. Using the
dh_auto_configure
command is better than the
./configure
command here since it will only override the
--sysconfig argument and keeps well intended other arguments to
the ./configure
command.
If Makefile
of a source for gentoo
requires you to
specify build as its target to build it [32], you create an
override_dh_auto_build target to enable it.
override_dh_auto_build: dh_auto_build -- build
This ensures to run $(MAKE) with all the default arguments given by the
dh_auto_build
command and build argument.
If Makefile
of a source for gentoo
requires you to
specify the packageclean target to clean it for Debian package
instead of the distclean or clean targets in the
Makefile
file, you create an override_dh_auto_clean
target to enable it.
override_dh_auto_clean: $(MAKE) packageclean
If Makefile
of a source for gentoo
contains
test target which you do not want to run for the Debian package
building process, you can use empty override_dh_auto_test target
to skip it.
override_dh_auto_test:
If gentoo
has an unusual upstream changelog file called
FIXES
, dh_installchangelogs
will not install that
file by default. The dh_installchangelogs
command requires
FIXES
as its argument to install it. [33]
override_dh_installchangelogs: dh_installchangelogs FIXES
When you use the new dh
command, use of explicit targets such as
the ones listed in Targets of rules
file,
Section 4.4.1 except get-orig-source target may make it
difficult to understand their exact effects. Please limit explicit targets to
override_dh_* targets and completely independent ones, if
possible.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
Debian New Maintainers' Guide
version 1.2.25, 2010-12-22 12:44:34 UTCjoy-mg@debian.org