[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ A ] [ next ]
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:
Correct the problem in the package source, of course.
Add a new revision at the top of the Debian changelog file, for example with `dch -i`, or explicitly with `dch -v <version>-<revision>' and then insert the comments using your preferred editor.
Tip: how to easily get the date in required format? Use `822-date', or `date -R'.
Include a short description of the bug and the solution in the changelog entry, followed by this: "Closes: #54321". That way, the bug report will be automagically closed by the archive maintenance software the moment your package gets accepted in the Debian archive.
Repeat what you did in Complete rebuild, Section 6.1, Checking the package for errors, Chapter 7, and Uploading the package, Chapter 8. The difference is that this time, the original source archive won't be included, as it hasn't been changed and it already exists in the Debian archive.
Now let's consider a different, slightly more complicated situation - a new upstream version was released, and of course you want it packaged. You need to do the following:
Download the new sources and put the tarball (e.g. named
`gentoo-0.9.13.tar.gz') in the directory above the old source tree
(e.g. ~/gentoo/).
Enter the old source directory, and run:
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.
Change directory to `../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 a `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 the resulting packages in detail. Here is a more realistic example of this procedure.
Verify changes in upstream source
Read the upstream changelog, NEWS, and whatever other
documentation they may have released with the new version.
Do a `diff -urN' between the old and new upstream sources to try to get a feel for the scope of the changes, where work is actively being done (and thus where new bugs may appear), and also keep an eye out for anything suspicious.
Port the old Debian packaging to the new version.
Unpack the source tarball and rename the root of the source tree as
<packagename>-<upstream_version>/ and
`cd' into this directory.
Copy the source tarball in the parent directory and rename it as
<packagename>_<upstream_version>.orig.tar.gz .
Apply the same kind of modification to the new source tree as the old source tree. Possible methods are:
`zcat /path/to/<packagename>_<old-version>.diff.gz | patch -p1' command,
`uupdate' command,
`svn merge' command if you manage the source with Subversion repository, or
simply copying debian/ directory from the old source tree if it
was packaged with dpatch or quilt.
Preserve old changelog entries (sounds obvious, but there have been incidents...)
The new package version is the upstream release version appended with a -1 Debian revision number, e.g., `0.9.13-1'.
Add changelog record entry with "New upstream release" for this new
version at the top of debian/changelog. For example `dch -v
0.9.13-1'.
Describe concisely the changes in the new upstream release that fix reported bugs and close those bugs in the changelog.
Describe concisely the changes to the new upstream release by the maintainer that fix reported bugs and close those bugs in the changelog.
If the patch/merge did not apply cleanly, inspect the situation to determine
what failed (clues are left in .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.
Upgrades to the new version should be silent and nonintrusive (existing users should not notice the upgrade except by discovering that old bugs have been fixed and there perhaps are new features). [4]
If you need to add erased template files for any reason, you may run
dh_make again in the same, already "debianized",
directory with -o option. Then edit it properly.
Existing Debian changes need to be reevaluated; throw away stuff that upstream has incorporated (in one form or another) and remember to keep stuff that hasn't been incorporated by upstream, unless there is a compelling reason not to.
If any changes were made to the build system (hopefully you'd know from step 1)
then update the debian/rules and debian/control build
dependencies if necessary.
Build the new package as described in The
debuild command, Section 6.3 or The pbuilder package, Section
7.6. Use of pbuilder is desirable.
Verify new packages are built correctly.
Check again to see if any bugs have been fixed that are currently open in the
Debian Bug Tracking System
(BTS) .
Check the contents of the .changes file to make sure you are uploading to the correct distribution, the proper bugs closures are listed in the Closes: field, the Maintainer: and Changed-By: fields match, the file is GPG-signed, etc.
If any changes were made to correct anything in the packaging along the way, go back to the step 2 until satisfied.
If your upload needs to be sponsored, be sure to note any special options required when building the package (like 'dpkg-buildpackage -sa -v ...') and be sure to inform your sponsor so he or she builds it correctly.
If you are uploading yourself, perform Uploading the package, Chapter 8.
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 of 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 using a source code management system to manage packaging activity. There are several wrapper scripts which are customized to be used with the most popular ones.
CVS
cvs-buildpackage
Subversion
svn-buildpackage
Git (git-core)
git-buildpackage
These commands also automate the packaging of new upstream releases.
When you build a new version of the package, you should do the following to verify that the package can be safely upgraded:
upgrade from the previous version
downgrade back again and then remove it,
install the new package
remove it and then reinstall it again,
purge it.
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.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ A ] [ next ]
Debian New Maintainers' Guide
[email protected]