Re: multiarch/bi-arch status (ETA) question
lsorense@csclub.uwaterloo.ca (Lennart Sorensen) writes:
> On Tue, Jul 05, 2005 at 04:25:39PM -0400, Stephen Frost wrote:
>> Pfft, give me a break. Guess we'll never move anything ever again.
>> That's just not how it works.
>
> No I am sure we will, we just won't claim it is a trivial change.A
>
> Starting to make a pile of symlinks without a plan certainly doesn't
> seem productive.
>
>> Actually you can put a symlink in /usr/lib to the actual library in
>> /usr/lib/i386-linux, if necessary.
>
> Per file yes.
>
>> That'd be why we need multiarch, yes. The symlinks can be used to solve
>> the problem when you can be sure of the answer, and as I recall there
>> was a proposal to have a 'default' for the system which would answer the
>> question when there's multiple options on the system.
>
> Well I think the solution for multiarch will involve changes to how
> ld-linux loads libraries and where it looks, although it could
> potentially be managed just using ld.so.conf, although I don't think
> that is necesarily the best place to handle it.
Since each arch has it's own ld the default path just gets extended to
include the new dir. Adding the dirs to ld.so.conf is a quick hack to
simulate this behaviour but not the goal.
> Of course there is also the issue of how to deal with calling the 32 or
> 64bit version of program x if you have both versions installed. Perhaps
> a helper tool to say run64bit version of x would deal with that, and
> your idea of having symlinks in the original location to a default
> version would deal well with that. If not specified you run the one
> that has the symlink.
Multiarch doesn't address this. Since programs are seens as doing the
same jobs in 32bit or 64bit having both flavours is
unneccesary. Couple that with the many many problems of moving /bin/*
and /usr/bin/* anywhere else and you see why this is specificaly
ignored.
We know some users want mozilla 64bit and mozilla+flash 32bit
installed in parallel. But I find that quite useless. Users that need
flash just have to suffer a (slightly) slower 32bit mozilla for normal
browsing too. The same can probably be said for most other cases where
you would want 32bit and 64bit flavours of a program around.
For the remaining cases, if any, the programs have to install as
prog-x.i386-linux and prog-x.amd64-linux and set an alternative prog-x
pointing on one of them. Or they install into /usr/lib/arch-os/prog-x/
and supply a wrapper in /usr/bin that picks one at runtime. Some
solution that the package itself makes and not the packaging system in
general.
[The wraper could check uname and "linux32 progx-x" and "linux64
prog-x" would pick the right one then.]
> Of course then there is things like data files in /usr/share which are
> not architecture specific. If you install the same version of both 32
> and 64bit for a package, then the files should match and just keeping
> one copy should be fine. If for some reason you install a different
> version of one of them (as would happen during upgrades) how do we
> resolve those files? They aren't always seperated into an architecture
> all package (which would of course be trivial to handle). Do we divert
> the files from the older version somewhere, and then remove it when the
> older one is upgraded to match the newer one? No point wasting disk
> space on identical files after all.
Packages are strictly split into _arch and _all debs. Any shared files
must be _all. There is also /usr/include for which most libs can share
one tree for all archs. There is no packaging system magic planed
here. This part is actualy the biggest chunk in porting to multiarch.
>> You can certainly have a symlink from /usr/lib/libx.so.1 ->
>> /usr/lib/i386-linux/libx.so.1, and if you have to pick one when there's
>> multiple options available then you'll just have to pick one and that's
>> life. Generally things that require this kind of hackery should be
>> fixed regardless.
>
> Yes, but it does need fixing if anything is dependant on it.
> Fortunately, we have the source code.
>
>> Depends on the 'default' setting of the box.
>
> That is reasonable.
>
> Len Sorensen
The plan is to add multiarch support step by step while having a
single arch system right up to the moment everything is ready. And
even after having single arch must be possible. People that want
pure64 should never be forced to install 32bit cruft as well and vice
versa.
MfG
Goswin
Reply to: