On Mon, 2012-02-13 at 22:43:04 -0800, Russ Allbery wrote: > If this is comprehensive, then I propose the following path forward, which > is a mix of the various solutions that have been discussed:
> * dpkg re-adds the refcounting implementation for multiarch, but along > with a Policy requirement that packages that are multiarch must only > contain files in classes 1 and 2 above. > > * All packages that want to be multiarch: same have to move all generated > documentation into a separate package unless the maintainer has very > carefully checked that the generated documentation will be byte-for-byte > identical even across minor updates of the documentation generation > tools and when run at different times. If packages have to be split anyway to cope with the other cases, then the number of new packages which might not be needed otherwise will be even smaller than the predicted amount, at which point it makes even less sense to support refcnt'ing. It also requires maintainers to carefully consider if the (doc, etc) toolchains will generate predictible ouput. Your proposal still requires papering over the other corner-cases. > * Policy prohibits arch-varying data files in multiarch: same packages > except in arch-qualified paths. Well, there's no escape from this any way you look at it, regardless of refcnt'ing or not. > * 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. This requires IMO multitude of hacks when the simplest and obvious arch-qualified pkgname solves this cleanly, and allows debhelper to automatically deal with it. And for tools to just change where they always look for those files in the M-A:same case regardless of the package being binNMUed or not. This still does not solve the other issues I listed, namely binNMUs have to be performed in lock-step, more complicated transitions / upgrades. And introduces different solutions for different problems, while my proposal is generic for all cases. So this is still pretty much unconvincing, and seems like clinging into the refcnt'ing “solution” while it makes things overall more complicated, will introduce inconsistency and incertainty to maintainers, needs way more global changes to keep it going, etc. What I'd change to my proposal in the summary mail, is that arch-indep files might be considered for splitting at maintainers discretion, when it actually seems worth it, in the same way we've handled splitting arch-indep files from arch:any up to now. So for example a couple of headers could be kept on the -dev package, or Ian's case on essential and data files could also be kept on the same lib package, as long as their paths are arch-qualified either trhough a pkgname:arch or the multiarch triplet. This would reduce even more the amount of newly split packages. regards, guillem -- 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/20120214140138.ga23...@gaara.hadrons.org