Erinn Clark <[EMAIL PROTECTED]> writes: > * Erinn Clark <[EMAIL PROTECTED]> [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! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]