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/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120214073923.ga...@rivendell.home.ouaza.com
