Posted Jul 13, 2006 3:20 UTC (Thu) by elanthis
Parent article: The end of the multiarch era?
The author essentially is complaining "Fedora's pathetic RPM 'support' of multi-arch blows chunks" and thus he concludes that multi-arch is doomed.
Excellent logic there.
The problem really is Fedora and RPM. Multi-arch support there is based solely off of a coincidental feature of RPM to allow multiple copies of the same package to be installed at the same time. A small hack allows two copies of the same package but with different architectures to be installed and to not cause file conflicts. However, when the packages are not *perfectly* in sync, this small hack fails, RPM tries to install both packages, but file conflicts ensure.
This is stupid.
A proper multi-arch system would not blindly repackage every single piece of software for both architectures as two monolithic packages. An intelligently designed system would split arch-independent files into their own packages/components. Thus, for example, install AppFoo would entail installing appfoo-bin.x86 and appfoo-common.all. Want to install the AMD64 version, too? Install appfoo-bin.amd64, which would not have any file conflicts with appfoo-bin.amd64. They are entirely two separate packages and do not really on any hacks.
Now, let's not also get into the absurdity of *having* AppFoo for both x86 and AMD64. What exactly is the purpose of having two copies of an application installed? Nothing. Only things which *need* multiple archs should have multi-arch packages. That would essentially be frameworks and libraries. It makes sense to have an x86 and AMD64 version of libpng, but not OpenOffice.org. At least for your average work station. It turns out there *is* a use for having both archs for an application installed.
The author also ignores the fact that multi-arch is useful far beyond simply AMD64 machines. Imagine, for example, having a server which exports NFS-mounted file systems to thin clients. Some of the thin clients are x86 machines, some of them are ARM machine, some of them are PPC, etc. You *could* setup multiple NFS mounts and go through all the pain of keeping the package selection and configuration in sync. You could also just install a multi-arch system. One copy of every config file, one master package list, but binaries for all requires archs are installed. The different architectures' NFS mounts differ only in the symlinks pointing to the proper arch-dependent directories.
Getting back to average workstations, multi-arch is still useful, at least for frameworks and libraries. So all of your open source apps are now 64-bit clean, hmm? Good for you. For many of the rest of us, this isn't the case. I still have several open source apps that aren't 64-bit clean and are way too complicated for me to fix. I still have a number of x86-only closed-source apps (oh the horror!) that I am either stuck with (i.e., at work, there are proprietary apps for which no open source equivalent exists) or that I greatly desire (like games; which, frankly, I'd sooner replace my OS to play rather than dump them so that I can hold up some ethical feel-good mantra that doesn't let me do anything particularly entertaining or useful with my $3,000 chunk of hardware).
Finally, even if within the next year all the x86-only apps anyone ever needs get ported to AMD64, what happens when the next architecture switch happens? Another 5 years of slow, painful migration? With a proper multi-arch system in place, that can be made as painless as the Mac switchover from PPC to x86. Heck, maybe even *more* painless.
Multi-arch isn't going anywhere. There is an era beginning, if anything, not ending. Just because Fedora sucks rocks at multi-arch doesn't mean that multi-arch is dead, is unfeasible, or not useful. It just means Fedora sucks. Let some of the competing, much better thought out alternatives rise up. Then consider whether multi-arch is a goner or not.
to post comments)