Re: Temporary solution for changelog problem in binNMUs
Hi,
On Mon, 13 May 2013, Guillem Jover wrote:
> 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 already suggested that we should compare the Source version instead
for the case of M-A: same packages. Do you consider that ugly as well?
For the changelog handling, I tend to agree with Guillem that moving it
to control.tar.gz makes sense (and copyright/NEWS.Debian probably too).
But ansgar's objection about the duplication of the changelog in multiple
.deb when it used to be shared via a symlink also makes sense. As does the
fact that there's currently no way to not install some control files.
He also mentionned that having to fork dpkg to parse all changelog files
is really not very good from a design point of view. It would be better if
we already had a stable libdpkg that we could use to avoid those forks.
It would also be nice to offer some transition periods with compatibility
symlinks but that's not something that can be cleanly implemented outside
of dpkg (unless duplicating the files is deemeed acceptable).
Clearly, if we want to get some broader buy-in for this change, we must
try to come up with solutions to those problems.
For the compatibility symlinks, we can create a new binary package in
the dpkg source that would set them up, keep them up-do-date, and drop
them on removal.
The other points are more difficult to solve but would be useful in their
own to avoid the problem of small packages considered too heavy due to
their meta-data. It might be worth to think a bit about it. What about
allowing us to define some package like this in debian/control:
Package: foo
Extends: bar
Description: <summary>
This new "Extends" field would imply that all meta-data (including other
missing control fields) is shared with the bar package and at build-time
it transparently gets a supplementary "Depends: bar (= <foo-version>)" but
the .deb would not have any changelog/copyright.
(To further save meta-data space, we could have a way to factorize the
part of the description that describes the source package)
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
Reply to: