[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: BSD ports and multiarch

It's an idea that needs exploration. I've done something similar, running native libc vs. glibc on FreeBSD. It was helpful to hack ld.so's default paths.
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?
Reply to: