Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, 2012-02-08 at 13:19:17 +0000, Ian Jackson wrote:
> Well, it does mean that you might be lacking important information
> because the other changelog wouldn't be present on the system.
While the implicit Replaces seems the easy way out, it just seems even
more fragile than the shared files approach.
And while the binNMU changelog issues might seem like a corner case,
it's just a symptom of something that's not quite right. And after
this was brought up again I started considering that the shared file
approach might have been flawed afterall, even if it might have seemed
neat at the time (it's one of the reasons that part of the code has
not been merged yet). The main reason it was enviaged was to handle the
changelog and copyright files and to avoid needing to introduce an
additional common package per source, for just those two/three files.
As a side remark, I think at least those two are actual package
metadata and do belong in the .deb control member [0], and as such in
the dpkg database. But that's for discussion on another time, because
that would not fix the issue as upstream changelogs do conflict too,
for example.
<http://lists.debian.org/debian-dpkg/2011/09/msg00029.html>
> One thing which no-one yet seems to have suggested is to have
> multiarch:same packages put the changelog in a filename which is
> distinct for each architecture. (It wouldn't have to be the triplet;
> the shorter Debian arch would do.) Perhaps there are obvious reasons
> (which I have missed) why this is a terrible idea, but it seems to me
> that it's something we should consider.
Instead of this, I'd rather see the shared files approach just dropped
completely, and /usr/share/doc/ files for “Multi-Arch: same” packages
be installed under /usr/share/doc/pkgname:arch/. This would solve all
these problems in a clean way for the common case with just the two or
three mandated files (changelog, changelog.Debian and copyright), if
a package provides lots more files then they should be split anyway
into either a libfooN-common libfoo-doc, or similar. And finally this
would not be really confusing, given that one of the last interface
changes was to make all dpkg output for all “Multi-Arch: same”
packages be always arch-qualified.
regards,
guillem
Reply to: