Re: dpkg musings
On Mon, Mar 01, 2004 at 01:25:03PM +0100, Wichert Akkerman wrote:
> * N-arch setup / architecture & OS revisions
>
> I would like to have bi-arch be a simple form of N-arch setup, I don't
> feel it makes sense to limit us to two options. Ideally it would be nice
> to move both architecture and OS/kernel ABI into normal package
> dependencies. This allows you to run ia32 packages on different
> architectures simply be installing a plex86 package that Provides:
> arch-ia32 for example. The package system could pull in architecture
> emulators and kernel emulators (like icbs2) on demand. This should
> also work for biarch systems.
This would be very helpful in the long-term, with things like NetBSD or
FreeBSD on amd64 or ia64, where we might very well be capable of
running 4 or so different binary emulations. (Linux vs. BSD binaries,
and 32 vs 64 bit.)
In the shorter term, ia64, sparc(64), s390(x) and amd64 all already
have these problems with dual 32/64 bit environments.
> The problem is that we have two kinds of dependencies: arch-specific
> and arch-independent. For example a dependency on bash is arch-independent
> since we really don't care of our bash is running 32bit, 64bit or
> on an emulated processor: as long as it can run scripts it'll suffice.
> But for a library this is different: you want a library that uses
> the same architecture and kernel ABI as your application.
>
> My current thinking of how to implement this is to add some kind of
> constraints to dependencies so you get something like
>
> Depends: bash, libc (>= 2.3) [i386, linux]
>
> which dpkg already partially supports (Adam has been working on that).
> The things between [..] than change form being architectures to
> selection criteria: 'only accept libc of it satifies these additional
> constraints'.
I would really like to see a capability to say that a package needs an
i386, but doesn't care what kernel it runs on, or that it runs on linux,
but doesn't care what processor. Today, this is a real pain.
For many packages, this isn't really that big of a deal, but there are
some like gcc or X where things can get complicated.
> A problem with N-arch support is paths. rpm apparently does some horribly
> path rewriting where paths are changed during unpack depending on what
> architecture you unpack on. I strongly feel that is something we should
> not do since it means a package can no longer rely on where its contents
> will be on disk. This seems a FHS/LSB/policy problem: for libraries
> it is essential to prevent collisions so we will require something like
> /lib/<arch>-<abi>/ . To some degree we already have this (OpenSSL
> uses it for example). Having abi in there is useful since we are going
> to want to use that on FreeBSD and similar systems which can run both
> FreeBSD and Linux applications. I suspect this will be the hardest part
> to implement since it both means lots of coordiation with other
> distributions and lots of interesting moving around of things. And we'll
> run into fun things as well (like 64 bit application accessing utmp which
> is also written by a 32bit daemon writing in a different format).
I think you're on the right track with /lib/<arch>-<abi>/.
This is a fairly large issue. I can run most Linux binaries on my
freebsd-i386 system. Getting to a point where these things can coexist
under dpkg seems very hard to reach. (Heck, getting freebsd-i386 working
is hard enough!)
There are also some interesting issues with -dev packages. If we support
mixed-arch systems, how do we handle /usr/include? Do we need
/usr/<arch>-<abi>/include and /usr/<arch>-<abi>/lib?
Also, some programs can't and won't work in these kinds of environments.
It would be good to be able to (ab)use Conflicts similarly to the
proposed extended Depends. That way I can tell dpkg that util-linux
built for i386 really hates the freebsd kernel, so don't try to install
it...
---Nathan
Reply to: