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
