Re: Future of multiarch?
> On 4/9/05, Thomas Steffen <steffen.list.account@gmail.com> wrote:
> >
> > In general, I agree with the proposal on
> > http://www.linuxbase.org/futures/ideas/multiarch/, but I think it is
> > missing a crucial step: /bin also needs to be separated.
The difference between stuff in /bin and /lib is that the names of stuff in
bin are important to the user because she has to type that name to run it.
Libraries in /lib OTOH, are handled automatically by ldd.
Since the different binaries are going to have to have different names so the
user can distinguish them from each other, there is no value in putting them
in separate subdirs under /bin. You're better off just adopting a standard
name extension for these things and having mozilla-browser-amd64 and
mozilla-browser-i386, and then setting up an /etc/alternatives symlink called
mozilla-browser to point to which one the user prefers as the default.
All of that however can be done outside of the LSB Multiarch proposal. In
fact it can be done unofficially within Debian as long as the DD's
responsible for mozilla-i386 and mozilla-amd64 are willing to cooperate with
one another and have their package's install scripts share
the /etc/alternatives symlink. This is really what the /etc/alternatives
mechanism is designed for, so for Debian at least, that would be how to solve
the problem.
Keep in mind, that all this effort is to handle just a small number of cases,
most of which are temporary and will be solved the proper way some time in
the future, like OO (and all other FOSS) eventually getting fixed so it can
compile and run in 64 bit mode, various closed-source drivers being updated
by their owners to work in the environment where many of their users are now
moving too (64bit), or like 32bit Flash being replaced by an open-source
equivalent that works in both 32bit and 64bit for example, assuming
Macromedia chooses to ignore its customers.
Once you take all those cases away, what you're really left with is just old
proprietary closed-source software whose owners no longer exist or are
uninterested in supporting their Linux users. There is no good solution to
those remaining cases, except to stand as excellent examples to people in
the future that they should stick to open source software to avoid being
abandoned by a profit-oriented company that might one day fold up and
disappear on them. The best solution here is to bite the bullet and drop the
old software in favor of something newer, even if the alternatives aren't
quite as good as the old. The newer stuff at least has a future, and might
get as good as the old eventually.
Reply to: