[M3devel] multiarch

[Jay]

I think Python code simply depends on the Python interpreter.

I skimmed through the document.

The point I gleaned about interpreters is that sometimes a dependency is on an interpreter because the package is a "plugin" or "extension" written in C or such, and sometimes the dependency is because a program is written in "pure" Python (Tcl, Perl, etc.) and just needs "any" interpreter that will run.

 

That is, if I have:

hello.py:

print("hello")

 

I am dependent on Python, but on an AMD64 system, it can be the x86 Python or AMD64 Python (or heck, Jython or IronPython, implementations in Java and for .NET/Mono).

 

I see your point that Python could be considered an "architecture" and the Python interpreter could be seen as installing the processor. I didn't get that from the spec but should read it more closely.

 

There were some references here to qemu that I didn'd understand but might make sense in that light.

That is, maybe, maybe I could have "all architectures" in one file system and maybe some virtualization products use the host file system as a file system and not just store some virtual disk in it.

 

I agree OpenBSD is a bit spartan/draconion/etc.

 

My point about source builds was more to reflect the seeming "OpenBSD way" (Gentoo, SourceMage, etc.), not necessarily what is or should be the Modula-3 way. There's a real dilemna between the two options of binary packages and source builds. They each have advantages/disadvantages.

 

 - Jay
 
> Date: Sat, 4 Jul 2009 13:02:37 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] multiarch
> 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090704/8cd5580a/attachment-0002.html>