[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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: