Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 05:13:20PM +0100, Guillem Jover wrote:
> 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 , 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.
> > 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.
If you remove the shared files approach, how do you handle files like
lintian overrides, reportbug presubj and scripts, etc. ?