Re: developers-reference: Acknowledging NMUs
On 07/01/15 15:43, Guillem Jover wrote:
> On Tue, 2015-01-06 at 13:25:39 +0100, Jörg Frings-Fürst wrote:
>> After some discussions it is consensus that all changelog entries must
>> included.
>
> I don't agree with this. If the NMU is not good, or I don't agree with
> it, I'll not be including the changes in my VCS just to revert them,
> nor I'll want to pollute the changelog with stuff that never made it in.
I'm inclined to agree. What I *would* say that's stronger than the
current wording is: the changelog entries *of versions that are an
ancestor of your version* must be included; and anything that changed,
but is not listed for some other version further down the changelog,
needs to be listed in the top version instead.
(Think of the ancestry graph in gitk, or the graph in the top right
corner of BTS bug pages.)
If you have chosen to reject the changes from an NMU entirely, because
you don't think they're sensible - e.g. perhaps they hide the symptoms
of a serious bug by just deleting the assertion that fails, without
really fixing the root cause - then the changelog should reflect that by
*not* including the NMU's changelog entry. That means that any bugs
closed in the NMU are still considered open in your version unless/until
you fix them differently, and close them yourself - and that is entirely
correct, because the NMUer's proposed fix for the bug isn't in your
version either.
When dealing with branched packages, I don't always include entire
versions' changelogs from other branches verbatim, because sometimes
that would be more confusing: debian/changelog is linear, and the
branching structure isn't. So I sometimes opt to do something like this,
copying in the individual changes:
dbus (1.9.6-1) experimental; urgency=medium
* New upstream release to harden dbus-daemon [...]
* Merge from unstable:
- preinst: partially revert change from 1.9.4-2. It seems that
[...] (Closes: #773107, #773838)
- postinst: don't run dpkg-statoverride with [...]
(where the indented preinst and postinst changes were originally seen in
unstable, without the extra indent), and I think that's also a valid
thing to do.
S
Reply to: