[M3devel] multiarch

[hendrik at topoi.pooq.com]

On Sat, Jul 04, 2009 at 06:48:19AM +0000, Jay wrote:
> 
> The Python thing as I understand it, is that sometimes package foo 
> depends on package bar, and they must be of the same architecture, and 
> sometimes not. Specifically inproc "plugins" require matching  
> architecture, but if I just run an executable, architecture doesn't 
> usually have to match.

An executable has to be one of the architectures the processor will 
handle.  And if it uses shared libraries, they have to have matching 
architecture.  The whole worry about multiarch on Linux AMD-64 is to 
have a consistent way of identifying the compatible one of a set 
of same-names libraries, and doing this in such a way that it 
generalises to more architectures (because they *will* eventually show 
up) and won't confuse the package manager.

I think the real point with python is that python code is 
architecture-independent, because it's handled by an 
architecture-dependent interpreter.  Which makes it, in effect, an 
extra architecture that's available everywhere, whether you have an 
AMD-64 or other multiarch CPU or not.

> OpenBSD sets an interesting counterexample -- no biarch/multiarch,
> just one architecture, "same as it ever was", "no additional 
> complexity", everything is built from source anyway".

And they probably do not in any way support 32-bit proprietary 
binary-only device drivers or Flash interpreters or anything like that 
on AMD-64.

Building from source is the traditional Modula-3 way of handling 
packages.  To do this with the Debian package-manager, we'd have to 
include an install-dependency on cm3-min and let the post-install 
script use the compiler to compile the package and ship it to the 
proper place.

How to do this multiarch is not clear -- We might end up with a number 
of different architecture versions of the packages, which have identical 
contents (they're source code).  Being labelled with different 
architectures might (here's hoping the multiarch project thinks of this) 
end up invoking the appropriate cm3-min binary ...

I suspect having real binary packages for different architectures is the 
Debian way, however.  Using source packages is the norm on gentoo.
And cm3-min would have to be binary in any case, otherwise there would 
be no way to compile it.

But the multiarch stuff might indicate where we want to ship our 
libraries to.  Not bin/lib, but to some other  bin/lib-linux-ia32 
or whatever the multiarch people choose.  We're already using similar 
conventions in the choince of LINUXLIBC6 and such names.

-- hendrik