Re: multiarch/bi-arch status (ETA) question
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.
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.
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.
> 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
Reply to: