[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
seem productive.

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 whole directory?

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.



Reply to: