Posted Jul 13, 2006 16:12 UTC (Thu) by incase
In reply to: Misguided
Parent article: The end of the multiarch era?
> To make it quick because I have other things to do :
> - rpm will allow multiple package to own the same file without conflicts
> if the file checksums match (so multiple packages owning the same file
> is not an indication of packagers not having made the effort to put in
> common what could be - it means sharing is transparent to the user)
However, this is precisely the problem with RPM and file conflicts. In the original article, the i386 version of OOo conflicted with the AMD64 version because they contained different versions of the same file (or at least that seems to be the reason here).
The "sharing" of files between RPM packages caused me a lot of trouble back in my suse/redhat/mandrake days, because each time two packages sharing the same file became out of sync for whatever reason, I had to remove one of those packages, usually causing the removal of several other packages along with them because of their dependencies.
Sharing file between packages would only work if a newer package could update the shared file _without_ removing the other package(s) which also contained that file. However, this would mean that file revisions needed to be tracked inside the packages, which would cause a lot more trouble then simply moving such files to their own packages.
> - Fedora will not install by default duplicate versions of everything
> under the Sun, if an i386 package is installed that's because the
> user asked to install an i386 app needing this package once upon a time
> - rpm will silently clobber binaries in /usr/bin and friends(this is the
> only exception to the rules above), because multilib support is here
> for libs and the user does not need two ersions of the same executable
> installed. While an x86_64 lib can only link to other x86_64 libs,
> executable calls to not care which arch the executable was build for
This sounds to me (i.e. I haven't checked wether this is true, but from all I know about RPM, it should be) as if RPM doesn't make any difference between dependencies on a package libX containing libraries, which obviously need to be of the same arch as the package depending on it and a dependency on package Y for which only the outside behaviour (network, commandline, pipes, but not DLL loading/calls) matters. Which means that a package A of arch i386 depending on mysql-server will pull in the i386 version of mysql-server even though the AMD64 version of mysql-server is already installed. If that is true, I wouldn't call that true multiarch support.
to post comments)