Re: multiarch status update
Peter 'p2' De Schrijver <p2@mind.be> writes:
>> > Being able to install multiple versions is some use to multiarch, but
>> > could also be used for other things, such if two packages provide the
>> > same binary (git for example).
>> > Or to install multiple 'version 'numbers' of the same package.
>>
>> The big problem then is when to install multiple versions of a binary?
>> How should the depends decide when that is needed or wanted and when
>> not? Esspecialy when different versions are available per
>> architecture.
>>
>
> One way of doing this would be to make a binary a special directory
> which contains the actual binary files for the architectures the
> binaries exist. AIX 1.x did this and allowed transparent execution of
> binaries in a heterogenous cluster. So if you would start a binary on
> IA32 AIX machine which only existed in a mainframe AIX version, the
> system would automatically start the binary on one of the mainframe AIX
> nodes in the cluster. If an IA32 AIX binary was available, it would
> locally start this binary. The 'binary directory' had the name, the
> binary would normally have. The actual binary files get the architecture
> name they implement as the filename. Eg: there would be an /bin/ls
> directory containing 2 files : i386, ibm370.
>
>> How would programs or user specifiy what binary to call? How would
>
> You could explicitly start /bin/ls/i386 I think (which would fail if
> you did it on the wrong machine).
>
>> users even know which binary is which if they have the same name and
>> both packages are installed on the system? Just imagine the confusion
>> of a user installing foo (which provides the same binary "foo" as bar)
>> and calling foo gives him bars "foo".
>>
>> That is totaly out of the question. Packages that provide the same (by
>> name) binary (or even just file) MUST conflict. period.
>>
>
> I don't think so. I see at least a few possible uses for this :
>
> 1) have a shared filesystem between machines of multiple architectures
> 2) test your programs on architectures you don't have by using qemu
It might have its use there but it can't be simply done. The files
from two packages must be disjunct. That was my point. Moving binaries
into subdirs and calling them by their arch (e.g. /bin/ls/i486) would
solve that. But something has to do this change. Either the packaging
itself or dpkg when unpacking the deb. Both would mean a major change
in what we (and everybody else) currently have.
Lets say we do add special dirs for binaries and let dpkg manage
them. How would that work with old and new debs mixed together? Should
dpkg move all binaries into subdirs on upgrade once? Should it move
binaries into subdirs when a second arch gets installed?
Also what architecture should be called on x86_64 if both are there?
i486 or amd64? Should that be configurable?
I imagine that would need kernel support to work for "#!/bin/sh" and
the like which again raises the question of compatibility.
Weigh the gain against the work and hopefully you will see that the
cost outweigh the gain by a lot. If you want to share a filesystem to
i486 and amd64 systems I guess you could use a unionfs for amd64 that
has i486 as base and then just adds the 64bit stuff. Thats probably
far simpler and better than adding the complexity to dpkg.
> L & L
>
> p2.
MfG
Goswin
Reply to: