Re: Temporary solution for changelog problem in binNMUs
Hi!
On Mon, 2013-05-13 at 11:14:07 +0200, Ansgar Burchardt wrote:
> There have been previous discussions how to fix this[2]. The dpkg
> maintainers would like to treat changelogs and copyright files as
> metadata and move them out of /usr/share/doc[3].
>
> [2] <https://lists.debian.org/debian-dpkg/2012/07/msg00017.html>
> [3] <http://bugs.debian.org/681289>
The binNMU issue entails two “sub-problems”. The first is the one
introduced by different entries in binNMUs on multiple architectures.
The other is the unmatched versions for possible out-of-step binNMU
versions.
Personally I see very clearly what's the best/clean solution for the
first. For the second, I'm happy to declare it a “non-problem”, and
that it's what it is; if a package is M-A:same, then well, all arches
need to have the same version (as my proposal to not require same
version for M-A:same was shot down on the mega-thread in debian-devel);
as I've not seen any solution that does not complicate or uglify things
in very unnecessary ways, by way of revertig us back to having a
sort-of-revision in a different field, or hacking the version comparison
logic to special case binNMU-versions (ugh), etc.
> I believe it will still take a while to reach a consensus and implement
> it. So I would like to propose a temporary solution until this is sorted
> out:
>
> Let dh_installchangelogs split out the binNMU changelog entry into a
> changelog(.Debian).$arch.gz file for now.
>
> Yes, this might not be the final solution, but at least binNMUs
> shouldn't break any longer, at least as long as they have the same
> version across all architectures.
I've mentioned this before, I find this completely unsatisfactory,
because (at least):
1) the changelog stops representing the actual changelog of the
package.
2) the changelog is metadata anyway.
3) even if temporary, extractors might start looking into it.
4) even if temporary, we'll end up with uploaded packages with the
information in a different place, if we go with a different solution,
that will be 3 places where this can be found, and need supporting.
5) we could instead just decide now, and change the packaging helpers
once and be done with it, new packages will not suffer the problem
any more. The solution to consider changelogs metadata is also the
easiest one, just place them in the DEBIAN dir, that's it. I'll
prepare a proposal for at least debhelper later today.
6) once “solved” I see there will be very low incentive to fix this
properly, or that “solution” might just end up being entrenched,
see what happened with the build flags being set by default by
dpkg-buildpackage...
Also detecting for now if a package cannot be binNMUed should be pretty
strightforward, just checking if it builds M-A:same packages should be
enough.
dpkg supports --control-show and --control-list (already in wheezy), which
can be used for stuff like:
$ dpkg-query --control-show dpkg changelog
for installed packages, for example. Or:
$ dpkg-deb --info foo.deb changelog
The concerns I remember having seen on this seemed pretty mild:
* The control.tar .deb member is only compressed with gzip so the
binary package might grow quite a bit (possibly, I'm working on
adding support for non-gzip compressors for the control member,
but it will not be usable until after jessie, but it will get
way better than the alternatives).
* changelog extractors will need to be updated (but these will need
to be updated in any case, to get correct information).
Thanks,
Guillem
Reply to: