> On 4/9/05, Thomas Steffen <[EMAIL PROTECTED]> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]