Posted Jul 13, 2006 11:42 UTC (Thu) by paulj
In reply to: Misguided
Parent article: The end of the multiarch era?
I'm afraid what's pathetic there is your misunderstanding of how multiarch works in Fedora
I'll back up his understanding over yours actually. He's 100% right in that RPM will allow "multiple copies of the same package to be installed at the same time ... and to not cause file conflicts.", just go and try it. It's a really *evil* quick hack to allow bad packages to still be installed, but at the cost of allowing bad packages to go unfixed for multi-arch problems (and hence leading to the problems below). That hack is the reason why RPM and multi-arch sucks so badly.
Now, the packagers may well do (indeed, have done) their best to split RPMs into arch-dependent and binary parts, however at the base level RPM will *not* complain if the packagers get it wrong and multiple ARCHes of a package try to install the same file, RPM just silently clobbers the file. The rare times that happens these days, it likely won't actually be an arch-specific file, so it won't matter much (except when you erase the rpm, bye-bye file - even though it should remain installed), but when it is an arch-dependent file, things just got broken. If it happens with a critical binary, your system might be hosed (rare, but still it makes rpm very dangerous on multi-arch IMHO).
The only work-around I know is to use exclusively use apt-rpm, which seems to implement its own file-conflict checking /before/ handing off to rpm/librpm, hence detecting such conflicts before allowing RPM to potentially run amok. Yum relies totally on librpm for conflict resolution (is what was told to me anyway on the fedora lists), hence provides no protection - packaging errors will clobber things.
Multi-arch isn't voodoo, IRIX inst handled it fine years ago - not by splitting up arches, but by allowing one package to provide files for multiple arches (you could, if desired, specify which arches you wanted, either specifically when installing a package or generally via configuration variables) - but not the same filename, hence file conflicts couldn't occur.
I suspect I'll get flamed mightily, particularly for the apt vs yum comment.
to post comments)