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

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


Reply to: