Another multiarch decision

[Goswin von Brederlow <goswin-v-b@web.de>]

Hi,

I cleaned up some more of the old multiarch patches and hit another
spot where a decision must be made:

----------------------------------------------------------------------
Unpacking libhello/i386 (from .../libhello/libhello_1.0_i386.deb) ...
dpkg: error processing /home/mrvn/src/libhello/libhello_1.0_i386.deb (--install):
 trying to overwrite `/usr/share/doc/libhello/changelog.gz', which is also in package libhello/amd64
----------------------------------------------------------------------

Every package must have a changelog and copyright and many also have a
Readme and NEWS file. Those and any other files in doc will collide
for multiarch.

Dpkg could rename the files for the non native architecture by
prefixing them with the architecture, e.g.
/usr/share/doc/libhello/i386_changelog.gz
or
/usr/share/doc/libhello/i386/changelog.gz

This could be done for just the standard files. But I think that is to
minimalistic. Many packages also have some examples or other small
files. Many packages would have to split them out into a tiny
<package>-common deb causing Packages.gz and the packages database to
bloat.

So I think for Multi-Arch: abi packages the /usr/share/doc/<package>
in its entirety should be renamed and now there is a choice to make:

1) Change policy

We could change policy to dictate that Multi-Arch: abi packages must
use /usr/share/doc/<package>_<DEB_HOST_ARCH>/ instead of the normal
directory. This would require some small changes in dpkg-* scripts and
debhelper. debian/rules for packages might not have to change at all.

This would also affect lintian, linda and packages.d.o.

2) Rename the files during extraction

This would require changes to dpkgs tar module. It would mean adding a
whole new rename mechanism or misusing the diversion code and I fear
would be somewhat complicated in the code flow.



I would prefer option 1. Irespective of the choice apt-listchanges
hase also to be changed.

MfG
        Goswin