Russ Allbery <r...@debian.org> writes: > 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. > > * Lintian should recognize arch-qualified override files, and multiarch: > same packages must arch-qualify their override files. debhelper > assistance is desired for this.
I think that, provided the files are byte for byte identical across architectures they need not be arch qualified. So they should be refcounted and having non-identical files across archs should be forbidden by policy. The maintainer must then resolve this by 1) making the file identical across archs or 2) arch qualifying the name. So lintian should support arch qualified names but policy should not needlessly require them. > * Policy prohibits arch-varying data files in multiarch: same packages > except in arch-qualified paths. > > * 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. > > Please note that this is a bunch of work. I think the Lintian work is a > good idea regardless, and it can start independently. I think the same is > true of the binNMU changelog work, since this will address some > long-standing issues with changelog handling in some situations, including > resolving just how we're supposed to handle /usr/share/doc symlinks. But > even with those aside, this is a lot of stuff that we need to agree on, > and in some cases implement, in a fairly short timeline if this is going > to make wheezy. In case /usr/share/doc/pkg is a symlink the binNMU changelog should be stored in the destination of the symlink. For this to work the (binNMU) changelog should be both arch and package qualified (changelog.Debain.bin-pkg.arch). This would allow libfoo:any, foo-bin:any + foo-common:all to be binNMUed. Without the package qualifier the libfoo and foo-bin package would both contain /usr/share/doc/foo-common/changelog.Debian.arch and produce a file overwrite error. After a binNMU (on amd64) the following files would exist: foo-bin: /usr/share/doc/foo-bin -> foo-common foo-bin: /usr/share/doc/foo-common/changelog.Debian.foo-bin.amd64 foo-common: /usr/share/doc/foo-common/changelog.Debian libfoo: /usr/share/doc/foo-common/changelog.Debian.libfoo.amd64 libfoo: /usr/share/doc/libfoo -> foo-common The binNMU changelogs would be identical wasting a little disk and mirror space and bandwidth but that is probably unavoidable. One way to reduce the overhead would be to split the binNMU entry into a separate changelog: foo-bin: /usr/share/doc/foo-bin -> foo-common foo-bin: /usr/share/doc/foo-common/changelog.binNMU.foo-bin.amd64 foo-common: /usr/share/doc/foo-common/changelog.Debian libfoo: /usr/share/doc/foo-common/changelog.binNMU.libfoo.amd64 libfoo: /usr/share/doc/libfoo -> foo-common The binNMU changelogs would be just one entry each, the reason for the binNMU. MfG Goswin -- 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/87d395zn6m.fsf@frosties.localnet