<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
I think Python code simply depends on the Python interpreter.<BR>
I skimmed through the document.<BR>
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.<BR>
<BR>
That is, if I have:<BR>
hello.py:<BR>
print("hello")<BR>
<BR>
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).<BR>
<BR>
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.<BR>
<BR>
There were some references here to qemu that I didn'd understand but might make sense in that light.<BR>
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.<BR>
<BR>
I agree OpenBSD is a bit spartan/draconion/etc.<BR>
<BR>
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.<BR>
<BR>
- Jay<BR> <BR>> Date: Sat, 4 Jul 2009 13:02:37 -0400<BR>> From: hendrik@topoi.pooq.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] multiarch<BR>> <BR>> On Sat, Jul 04, 2009 at 06:48:19AM +0000, Jay wrote:<BR>> > <BR>> > The Python thing as I understand it, is that sometimes package foo <BR>> > depends on package bar, and they must be of the same architecture, and <BR>> > sometimes not. Specifically inproc "plugins" require matching <BR>> > architecture, but if I just run an executable, architecture doesn't <BR>> > usually have to match.<BR>> <BR>> An executable has to be one of the architectures the processor will <BR>> handle. And if it uses shared libraries, they have to have matching <BR>> architecture. The whole worry about multiarch on Linux AMD-64 is to <BR>> have a consistent way of identifying the compatible one of a set <BR>> of same-names libraries, and doing this in such a way that it <BR>> generalises to more architectures (because they *will* eventually show <BR>> up) and won't confuse the package manager.<BR>> <BR>> I think the real point with python is that python code is <BR>> architecture-independent, because it's handled by an <BR>> architecture-dependent interpreter. Which makes it, in effect, an <BR>> extra architecture that's available everywhere, whether you have an <BR>> AMD-64 or other multiarch CPU or not.<BR>> <BR>> > OpenBSD sets an interesting counterexample -- no biarch/multiarch,<BR>> > just one architecture, "same as it ever was", "no additional <BR>> > complexity", everything is built from source anyway".<BR>> <BR>> And they probably do not in any way support 32-bit proprietary <BR>> binary-only device drivers or Flash interpreters or anything like that <BR>> on AMD-64.<BR>> <BR>> Building from source is the traditional Modula-3 way of handling <BR>> packages. To do this with the Debian package-manager, we'd have to <BR>> include an install-dependency on cm3-min and let the post-install <BR>> script use the compiler to compile the package and ship it to the <BR>> proper place.<BR>> <BR>> How to do this multiarch is not clear -- We might end up with a number <BR>> of different architecture versions of the packages, which have identical <BR>> contents (they're source code). Being labelled with different <BR>> architectures might (here's hoping the multiarch project thinks of this) <BR>> end up invoking the appropriate cm3-min binary ...<BR>> <BR>> I suspect having real binary packages for different architectures is the <BR>> Debian way, however. Using source packages is the norm on gentoo.<BR>> And cm3-min would have to be binary in any case, otherwise there would <BR>> be no way to compile it.<BR>> <BR>> But the multiarch stuff might indicate where we want to ship our <BR>> libraries to. Not bin/lib, but to some other bin/lib-linux-ia32 <BR>> or whatever the multiarch people choose. We're already using similar <BR>> conventions in the choince of LINUXLIBC6 and such names.<BR>> <BR>> -- hendrik<BR></body>
</html>