Re: New upstream packages?
Erinn Clark <erinn@double-helix.org> writes:
> * Erinn Clark <erinn@double-helix.org> [2004:12:18 18:23 -0500]:
> <snip>
>
> Of course, just after sending this mail, I was directed to:
>
> http://www.debian.org/doc/maint-guide/ch-update.en.html#s-newupstream
>
> ...which I somehow managed to miss. It's still a bit sparse, so any other
> tips people have for dealing with new upstream releases is very welcome.
First of all, I'll assume you've skimmed over the source as part of your
initial packaging. I usually go through the following steps:
1. Read the upstream changelog, NEWS, and whatever other documentation
they may have released with the new version.
2. 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.
3. Port the old Debian packaging to the new version. This basically
involves applying the diff.gz from the old package to the new one and
incrementing the debian/changelog. Tools like uupdate help automate
this for you. Personally I keep all of my packages in a subversion
repository and thus do an svn merge.
4. 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.
5. If any changes were made to the build system (hopefully you'd know
from steps 1 and 2) and update the debian/rules and debian/control
build dependencies if necessary.
6. Build the new package. Personally I always build in a pbuilder
chroot since I use some 3rd party packages on my system and I don't
want those interfering.
7. Verify that the new package builds correctly.
8. Run lintian to catch any obvious policy violations.
9. Run 'debdiff old-package.change new-package.change'. Verify that no
files have been unintentionally misplaced or removed, and no other
inadvertent changes were made.
10. Verify the contents with 'debc new-package.changes'. Ensure no files
are zero-length that should not be.
11. Install the new package. Verify it installs/upgrades correctly.
Verify that it works normally. If the package makes use of
non-trivial pre/post/inst/rm scipts, be sure to test the upgrade
paths of those.
12. Check to see if any bugs have been fixed that are currently open in
the BTS. If they have been, close them in the debian/changelog.
13. Check the sanity of the diff.gz file. Run 'interdiff -z
old-package.diff.gz new-package.diff.gz' and verify any
modifications changes are intentional and no junk files have crept
in.
14. 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.
15. If any changes were made to correct anything in the packaging along
the way, repeat steps 6-13 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.
Did I miss anything?
--
For every sprinkle I find, I shall kill you!
Reply to: