During a
recent thread on mentors [1], I learned that the purpose is to provide a human
readable list of changes between released versions of Debian.
Section 4.4 explains quite a bit about debian/changelog, but doesn't
really explain its purpose. I took its purpose to be recording history
and driving automation - which led to some mistakes that might've been avoided. During a recent thread on mentors [1], I learned that the
purpose is to provide a human readable list of changes between released versions of Debian. This came as a surprise.
Some people in debian-mentors will make very absolute statements about
never including unreleased versions in debian/changelog and always consolidating versions, and will give the impression that literally
everyone in Debian holds this view. This is not really the case. It's
*most common* to consolidate versions, and usually there's no point in keeping entries for unreleased versions, but this isn't a universal rule followed by every experienced Debian maintainer, and there are times when retaining entries for unreleased versions is useful (there were non-Debian releases of the package, for instance, or there's something about the development path that the maintainer felt was important to document).
Package: debian-policy Version: 4.1.1.1 Severity: normal
Section 4.4 explains quite a bit about debian/changelog, but doesn't
really explain its purpose.
On Wed, Oct 18 2017, Russ Allbery wrote:
It's probably worth noting here that while debian-mentors has
converged to a very strong consensus that unreleased versions of
packages should not appear in debian/changelog, the consensus about
that in the broader project is nowhere near as strong.
I was active on -mentors relatively recently and I don't think I
understand what you mean when you say "unreleased versions of packages
should not appear in debian/changelog".
Do you mean that successive uploads to mentors.debian.net are expected
to re-use the same Debian version number?
What actually matter is that the .changes file include the relevant
extract from the changelog and do not miss packaging change because they where listed in unreleased versions and dpkg-genchanges -v was not used properly.
It's probably worth noting here that while debian-mentors has
converged to a very strong consensus that unreleased versions of
packages should not appear in debian/changelog, the consensus about
that in the broader project is nowhere near as strong.
My impression of discussion on debian-mentors over the past few years
is that most of the people active in sponsoring have as a requirement
that all changelogs from versions of a package that weren't uploaded
to Debian be consolidated and the version of a new package upload, as
finally uploaded to the archive, always be one higher than the last
version uploaded to Debian proper.
This makes a lot of sense in the context of nearly all packages that
flow through sponsorship, and I realize it's a correction for the very
early days of mentors.debian.net when people tended to bump the
version for every package they made available for review, and there
were a ton of changelog entries generated from back and forth
discussions with mentors that never saw the archive. That's obviously
not very useful.
But I feel like that sensible guideline hardened, during repeated
discussion, into something that's sometimes presented as a hard and
fast rule that one should *always* do this in Debian packaging. Yet,
I've seen a lot of cases where experienced DDs retain intermediate
unreleased versions in the changelog for various reasons, so I'm a bit dubious of it as a concrete rule, even though it almost always makes
sense in the specific context of sponsored uploads.
Separate than the point that Policy could probably stand to say something
a little more concrete about the purpose of debian/changelog, I suspect
this came out of the recurring discussion of whether to include unreleased versions in debian/changelog.
On Tue, Oct 17 2017, Ross Vandegrift wrote:
Package: debian-policy Version: 4.1.1.1 Severity: normal
Section 4.4 explains quite a bit about debian/changelog, but doesn't
really explain its purpose.
Have you seen Developer's Reference 5.2? That gives more detail. I am reluctant to duplicate that in Policy.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 292 |
Nodes: | 16 (2 / 14) |
Uptime: | 186:16:15 |
Calls: | 6,616 |
Files: | 12,165 |
Messages: | 5,314,900 |