On Wed, 8 Feb 2012 02:52:52 +0200 Riku Voipio <riku.voi...@iki.fi> wrote:
> If it turns out not reasonable to expect the compression results to be
> identical, we should probably look into using dpkg --path-exclude= with
> /usr/share/{doc,man,info}/* when installing foreign-architecture packages.
That would be a suitable alternative to decompression checksums.
It sounds like an implicit Replaces: on the same package of any other
architecture for Multi-Arch: same packages limited
to /usr/share/{doc,man,info}/*.
> Very few Multi-Arch: same packages need to install identical compressed
> files outside these directories. In case it happens, the package needs to
> use multiarch paths or split files to -common package.
It's not that ugly - with a few looks at the list of problematic files.
e.g. libslang2-dev, in common with a number of other -dev packages,
includes a few example files in the -dev instead of using a -doc
package. The compression of those files causes conflicts in the -dev
package, at which point creating a -doc package doesn't seem that bad
an idea. Other options would be to not compress example files when
packaged inside -dev packages - after all, if the example files are
large enough for a lack of compression to matter, the examples should
be in a -doc package.
http://people.debian.org/~jwilk/multi-arch/same-md5sums.txt
> The ugliness of this
> solution is that the "specialness" of /usr/share/doc and others needs to
> embedded into the package system somewhere.
Packages can use multiarch paths for their own files, but there are
currently 80 occurrences of changelog.Debian.gz in the list of
problematic files. dpkg needs to handle that, packages have no option.
I'm wondering if /usr/share/{doc,man,info}/* is the right pattern.
Maybe it really is just /usr/share/*.
After all, this is how cross/foreign architecture packages have
*always* been handled in Debian via dpkg-cross. Nothing in /usr/share/
matters for a cross package created by dpkg-cross (with the possible
exception of /usr/share/pkg-config which was always anachronistic). Some
template files are added but the package name includes the
architecture, so these files are effectively in multiarch paths.
There is nothing useful in /usr/share of a Multiarch: same package
when installed as foreign architecture package. Emdebian & dpkg-cross
have proved that by having nothing else until Multi-Arch. Anything you
might need is in the native architecture package, so the best thing to
do is widen the implicit exclusion to all of /usr/share in the incoming
Multi-Arch: same package.
In the list, the only listings in the above file which are not
in /usr/share do look like bugs:
usr/bin/kvirc
usr/bin/croco-0.6-config
usr/bin/croco-0.6-config
usr/include/dspam/auto-config.h
usr/include/isl/stdint.h
usr/bin/magics-config
usr/include/OGRE/OgreBuildSettings.h
usr/include/pci/config.h
usr/lib/pkgconfig/popt.pc
usr/bin/ppl_pl
usr/bin/ppl-config
usr/include/ppl.hh
usr/include/ppl_c.h
usr/bin/ppl-config
usr/include/ppl.hh
usr/include/ppl_c.h
usr/lib/sasl2/berkeley_db.txt
usr/lib/libwrap.a
usr/include/XdmfConfig.h
usr/bin/whiptail
usr/lib/pkgconfig/popt.pc - needs to be a multiarch path
usr/bin/* is just wrong - bug reports invited.
usr/include/* means that the package concerned needs to use a multiarch
path for that include file(s).
That leaves:
usr/lib/sasl2/berkeley_db.txt
usr/lib/libwrap.a
.a files need multiarch paths, clearly.
So, apart from /usr/share which I can't see as important for
Multi-Arch: same packages, the list of remaining conflicts are bugs and
the gzip bug doesn't matter anymore.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
pgpJi9fyRhNvc.pgp
Description: PGP signature
