[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ A ] [ next ]
We should now be ready to build the package.
Enter the program's main directory and then issue this command:
dpkg-buildpackage -rfakeroot
This will do everything for you. It will:
clean the source tree (debian/rules clean), using fakeroot
build the source package (dpkg-source -b)
build the program (debian/rules build)
build the binary package (debian/rules binary), using fakeroot
sign the source .dsc file, using gnupg
create and sign the upload .changes file, using
dpkg-genchanges and gnupg
The only input that will be required of you is your GPG key secret pass phrase, twice.
After all this is done, you will see the following files in the directory above
(~/gentoo/):
gentoo_0.9.12.orig.tar.gz
This is the original source code tarball, merely renamed to the above so that
it adheres to the Debian standard. Note that this was created using the `-f'
option to dh_make when we initially ran it.
gentoo_0.9.12-1.dsc
This is a summary of the contents of the source code. The file is generated
from your `control' file, and is used when unpacking the source with
dpkg-source(1). This file is GPG signed, so that people can be
sure that it's really yours.
gentoo_0.9.12-1.diff.gz
This compressed file contains each and every addition you made to the original
source code, in the form known as "unified diff". It is made and
used by dpkg-source(1). Warning: if you don't name the original
tarball packagename_version.orig.tar.gz, dpkg-source will fail to
generate the .diff.gz file properly!
If someone else wants to re-create your package from scratch, they can easily do so using the above three files. The extraction procedure is trivial: just copy the three files somewhere else and run dpkg-source -x gentoo_0.9.12-1.dsc.
gentoo_0.9.12-1_i386.deb
This is your completed binary package. You can use dpkg to
install and remove this just like any other package.
gentoo_0.9.12-1_i386.changes
This file describes all the changes made in the current package revision, and it is used by the Debian FTP archive maintenance programs to install the binary and source packages in it. It is partly generated from the `changelog' file and the .dsc file. This file is GPG signed, so that people can be sure that it's really yours.
As you keep working on the package, behavior will change and new features will be added. People downloading your package can look at this file and quickly see what has changed. Debian archive maintenance programs will also post the contents of this file to the debian-devel-changes mailing list.
The long strings of numbers in the .dsc and .changes files are MD5 checksums
for the files mentioned. A person downloading your files can test them with
md5sum(1) and if the numbers don't match, they'll know the file is
corrupt or has been tampered with.
With a large package, you may not want to rebuild from scratch every time while
you tune a detail in debian/rules. For testing purposes, you can
make a .deb file without rebuilding the upstream sources like this:
fakeroot debian/rules binary
Once you are finished with your tuning, remember to rebuild following the above, proper procedure. You may not be able to upload correctly if you try to upload .deb files built this way.
debuild command
You can automate package build process further with debuild
command. See debuild(1).
Customization of the debuild command can be done through
/etc/devscripts.conf or ~/.devscripts. I would
suggest at least following items:
DEBSIGN_KEYID="Your_GPG_keyID"
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -ICVS -I.svn"
With these, you can build package always with your GPG key and avoid including undesired components. (This is good for sponsoring too.) For example, cleaning source and rebuilding package from a user account is as simple as:
debuild clean
debuild
dpatch and quilt systems
The simple use of dh_make and dpkg-buildpackage
commands will create a single large diff.gz file which contains
package maintenance files in debian/ and patch files to the
source. Such a package is a bit cumbersome to inspect and understand for each
source tree modification later. This is not so nice. [1]
Several methods for the patch set maintenance have been proposed and are in use
with Debian packages. The dpatch and quilt systems
are two of the simplest of such patch maintenance systems proposed. Other ones
are dbs, cdbs, etc.
A package which is packaged properly with the dpatch or
quilt systems has modifications to the source clearly documented
as a set of -p1 patch files with header in debian/patches/ and the
source tree is untouched outside of debian/ directory. If you are
asking a sponsor to upload your package, this kind of clear separation and
documentation of your changes are very important to expedite the package review
by your sponsor. The usage method of dpatch and
quilt is explained in dpatch(1),
dpatch-edit-patch(1) and quilt(1). Both programs
provide convenience files to include in debian/rules:
/usr/share/dpatch/dpatch.make and
/usr/share/quilt/quilt.make.
When someone (including yourself) provides you with a patch to the source later, then the package modification is quite simple:
Edit patch to make it a -p1 patch to the source tree.
In the case of dpatch, add header using `dpatch
patch-template' command.
Drop it into debian/patches
Add the patch filenames to debian/patches/00list (for
dpatch) or debian/patches/series (for
quilt).
Also, dpatch has a capability to make patches architecture
dependent using CPP macro.
orig.tar.gz for upload
When you first upload the package to the archive, you need to include the
original orig.tar.gz source. If package version is not at
-0 or -1 Debian revision, you must provide
dpkg-buildpackage command with the "-sa"
option. On the other hand, the "-sd" option will force
to exclude the original orig.tar.gz source.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ A ] [ next ]
Debian New Maintainers' Guide
[email protected]