On Wed, Feb 08, 2012 at 10:22:17AM +0000, Neil Williams wrote: > 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. The unfounded assumption here is that you will always install a foreign-arch M-A: same package together with the native-arch version. If I install libaudio2:i386 because I want to play a game that's only available as a 32-bit binary and has this lib as a dependency, and nothing else on my system uses libaudio2, I still expect to get /usr/share/libaudio2/AuErrorDB installed. In general, anything that introduces assymetric handling between native and foreign arch packages at the dpkg level is probably going to be a bad idea. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature