Re: multiarch/bi-arch status (ETA) question
On Tue, 5 Jul 2005, Lennart Sorensen wrote:
No I am sure we will, we just won't claim it is a trivial change.A
It looks trivial to make the new directories and links and _start_.
No such claims about the rest. :)
Starting to make a pile of symlinks without a plan certainly doesn't
It seems like there's a good plan already documented. I'm still trying to
find any objections to it that make sense; any at all, in fact...
Actually you can put a symlink in /usr/lib to the actual library in
/usr/lib/i386-linux, if necessary.
Per file yes.
Why bother making it hard when you can just make it easy and link the
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.
I don't see a problem here. The case seems rare; when it happens the order
of the elements in PATH dictates preference, and aliases (or any other
mechanism) can be used to override.
The common case is to deal with libraries for packages that aren't
available on both architectures anyway.
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
This sounds like a good example of what work will be involved in reforming
packages to deal with the new standard. Probably you end up with those
share files in "common" noarch packages that are a dependency of the
arch-specific ones. In fact I think I've seen packages doing that already.