Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Ben Finney <ben+debian@benfinney.id.au>]

Howdy all,

I see a conflict in the workflow of bug fixing and packaging. I'd like
to know that I'm wrong, or that I'm right but there is a way to get
around it.

As I understand it, the following facts hold:

* When a bug is fixed in a new release, recommended practice is to put
  a “Closes: bug#NNN” in the changelog at that specific release
  entry.

* When fixing bugs that prevented a previous release (e.g. one made to
  mentors.debian.net) from making it into Debian (e.g. because the
  sponsor requires further changes), recommended practice is to
  increment the release number and make a new changelog entry, to
  easily distinguish from any existing release.

* When packages are created by ‘dpkg-buildpackage’, the ‘*_changes’
  files by default contain only changes from the latest entry in the
  changelog.

So the conflict is that a bug fixed and marked as closed in the
changelog will *not* be found by the automated changelog parser
(what's the name of this process?) in the case when the bug was fixed
in a release that didn't actually make it into Debian.

For example: if package ‘foo’ at version ‘1.0-1’ exists in Debian, and
then a new version makes its way into Debian with the following
changelog:

    foo (2.0-2) unstable; urgency=low

      * Fixed bad debian/copyright; thanks to Boris Sponsor.

     -- Arthur Hacker <arthur@example.org>  Tue, 03 Jan 2300 18:47:31 +1100

    foo (2.0-1) unstable; urgency=low

      * New upstream release (closes: bug#98765432).

     -- Arthur Hacker <arthur@example.org>  Mon, 02 Jan 2300 07:52:04 +1100

    foo (1.0-1) unstable; urgency=low

      * Initial Debian packaging (closes: bug#9864264).

     -- Arthur Hacker <arthur@example.org>  Wed, 10 Nov 2298 07:52:04 +1100

When this changelog is processed by a default ‘dpkg-genchanges’ as
part of building the package, only the last entry (for version
‘2.0-2’) will be output. But there are *two* new releases in the
changelog since version ‘1.0-1’. The entry for ‘2.0-1’ never gets
examined for closed bugs.


Should it be normal, then, to always specify arguments to
‘dpkg-genchanges’ manually to specify which entries from the changelog
to include?

I never invoke ‘dpkg-genchanges’ manually; that's done by
‘dpkg-buildpackage’, which in turn is usually invoked by something
else (e.g. ‘pbuilder’ or ‘bzr-buildpackage’ etc.) Is there a normal
way to have ‘dpkg-genchanges’ always understand “include all entries
newer than what's currently in Debian”?

-- 
 \      “Progress might have been all right once, but it's gone on too |
  `\                                                long.” —Ogden Nash |
_o__)                                                                  |
Ben Finney