Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
On Mon, 13 Feb 2012, Russ Allbery wrote:
> There's been a lot of discussion of this, but it seems to have been fairly
> inconclusive. We need to decide what we're doing, if anything, for wheezy
> fairly soon, so I think we need to try to drive this discussion to some
> concrete conclusions.
Thanks for this.
> 2. Files like the above but that are compressed. This is most common in
> the doc directory for things like README or the upstream changelog.
> Upstream man pages written directly in *roff fall into this category as
> well, for -dev packages. With Steve's point above about gzip, I think
> we're probably okay using refcounting for this as well.
Yes, but I would still document at the policy level that, when feasible
without downsides, it's best to move compressed files in a shared package.
Also it might be wise to relax the policy rules on compression for
multi-arch: same and to let dh_compress not compress (some) files in such
packages.
> Does this seem comprehensive to everyone? Am I missing any cases?
It's a good summary, yes.
> If this is comprehensive, then I propose the following path forward, which
> is a mix of the various solutions that have been discussed:
I agree with this plan.
> * The binNMU process is changed to add the binNMU changelog entry to an
> arch-qualified file (changelog.Debian.arch, probably). We need to
> figure out what this means if the package being binNMU'd has a
> /usr/share/doc/<package> symlink to another package, though; it's not
> obvious what to do here.
I wonder what's the proper way to handle this. In theory, it would be nice
to deal with that at the dpkg-dev level but dpkg-dev is not at all
involved in installing the changelog. And I believe that the bin-nmu
process just adds a top-level entry to debian/changelog.
So the code should go to dh_installchangelogs... but it doesn't seem to be
a good idea to put the bin-nmu logic there in particular since we might
extend it (see #440094).
Somehow my suggestion is then to extend dpkg-parsechangelog to provide
the required logic to split the changelog in its bin-nmu part and its
usual content.
dpkg-parsechangelog --split-binnmu <binnmu-part-file> <remaining-part-file>
Then dh_installchangelogs could try to use this (and if it fails, fallback
to the standard changelog installation).
Does that sound sane? If yes, I can have a look at implementing this.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
Reply to: