Let's say that a bug report was filed against your package, #54321, and it describes a problem that you can solve. To create a new Debian revision of the package, you need to:
Tip: how to easily get the date in required format? Use `822-date', or `date -R'.
Now let's consider a different, a wee bit more complicated situation - a new upstream version was released, and of course you want it packaged. You need to do the following:
gentoo-0.9.13.tar.gz
') in the directory above the old source tree
(e.g. ~/gentoo/
).
uupdate -u gentoo-0.9.13.tar.gz
Of course, replace this file name with the name of your program's new source
archive. uupdate(1)
will properly rename that tarball, try to
apply all the changes from your previous .diff.gz
file, and update
the new debian/changelog
file.
../gentoo-0.9.13
', the new package source
tree, and repeat what you did in Complete rebuild, Section 6.1, Checking the package for errors, Chapter 7, and
Uploading the package, Chapter 8.
Note that if you set up `debian/watch
' file as described in watch.ex, Section 5.10, you can run
uscan(1)
to automagically look for revised sources, download them,
and run uupdate
.
When preparing packages for the the Debian archive, you must check resulting packages in detail. Here is a more realistic example of this procedure.
changelog
, NEWS
, and whatever other
documentation they may have released with the new version.
<packagename>-<upstream_version>/
and
`cd' into this directory.
<packagename>_<upstream_version>.orig.tar.gz
.
uupdate
' command,
debian/
directory from the old source tree if it
was packaged with dpatch
.
debian/changelog
. For example `dch -v
0.9.13-1'.
.rej
files). Most often the
problem is that a patch you applied to the source was integrated upstream, and
thus the patch is no longer relevant.
dh_make
again in the same, already "debianized",
directory with -o option. Then edit it properly.
debian/rules
and debian/control
build dependencies if necessary.
debuild
command, Section 6.3 or The pbuilder
package, Section
7.6. Use of pbuilder
is desirable.
Debian Bug Tracking System
(BTS)
.
orig.tar.gz
file
If you try to build packages only from the new source tree with
debian/
directory without the orig.tar.gz
file in its
parent directory, you will end up unintentionally creating a native source
package, which comes without the diff.gz
file. This type of
packaging is only appropriate for the debian-specific packages, which will
never be useful in another distribution. [5]
In order to obtain a non-native source package which consists with both the
orig.tar.gz
file and the diff.gz
file, you must
manually copy the upstream tarball to the parent directory with its file name
changed into
<packagename>_<upstream_version>.orig.tar.gz
as it was
done by dh_make
command in Initial "debianization", Section
2.4.
cvs-buildpackage
command and similesYou should consider to use some source code management system to manage packaging activity. There are several wrapper scripts which are customized to be use with the most popular ones.
cvs-buildpackage
svn-buildpackage
tla-buildpackage
arch-buildpackage
These commands also automate the packaging of new upstream release.
When you build a new version of the package, you should do the following to verify that the package can be safely upgraded:
If the package makes use of non-trivial pre/post/inst/rm scripts, be sure to test the upgrade paths of those.
Bear in mind that if your package has previously been released in Debian, people will often be upgrading to your package from the version that was in the last Debian release. Remember to test upgrades from that version, too.
Debian New Maintainers' Guide
version 1.2.3, 18 January 2005.joy-mg@debian.org