IIRC, I think you'd have to use /libarch rather than /lib/arch, or amend the FHS. This would also need to apply to /usr/lib, and possibly /usr/include. There are some advantages to this for non-BSD ports, since some archs already have multi-arch issues. (sparc64/sparc, ia64/i386, amd64/i386, and s390/s390x that I know of.)
There are two really ugly problems:
1. Some packages will work fine under emulation, but not all. IIRC, some essential packages fail to work under FreeBSD's emulation. Also, there are some headaches with making glibc and BSD libc share /etc.
2. dpkg might need major work to be able to deal with multiple archs which install the same libraries on the same system. Think about having libncurses for both linux and BSD. Both packages need to have the same name, otherwise dependacies won't work. dpkg would need to track installed packages by both name and arch, and do the same for dependacies. IMHO, this definitely won't make sarge.
---Nathan
Matthew Garrett wrote:
http://raw.no/debian/amd64-multiarch-3.txt contains a proposal for multiarch support on Debian. The basic idea would be that libraries will be installed in /lib/archstring and binaries installed as usual. Multiple library packages could be installed simultaneously, but only one of each binary package.
Why is this relevant? The obvious application to BSD ports is that it allows the use of Linux binaries without having any BSD-specific hacking. Linux-i386 (or whatever) libraries would go in /lib/linux-i386 and Linux binary packages could then be installed directly. This would allow for a much simpler bootstrapping of a port. Base can be ported without major effort. From that stage on, Linux packages could then be installed as a stop-gap - over time, more awkward packages can be transitioned to being BSD native.
There's something of a lag here. dpkg support for this functionality is unlikely to make sarge, so will have to wait until sarge+1, and packages requiring this functionality will have to wait until sarge+2 as a result. There's some interest in at least providing a sufficiently large number of packages to demonstrate proof of concept rather earlier than that, though. How do people feel about this sort of thing?