Misguided [LWN.net]

Misguided

Posted Jul 13, 2006 3:20 UTC (Thu) by elanthis (guest, #6227)
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.

(Log in to post comments)

Misguided

Posted Jul 13, 2006 11:42 UTC (Thu) by paulj (subscriber, #341) [Link]

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.

Misguided

Posted Jul 13, 2006 13:30 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

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)

- 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 versions 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

- Fedora dumped apt precisely because it did its own dep resolution different from the core system package manager, and differences in resolution rules caused much grief to users.

It certainly is possible to pour a lot of energy in making a more aesthetically pleasing system with no added benefits to the end users

Misguided

Posted Jul 13, 2006 16:12 UTC (Thu) by incase (subscriber, #37115) [Link]

> 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

True. However:

> - 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.

cu,
sven

Misguided

Posted Jul 13, 2006 18:16 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

> 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 article says the error message was:

/usr/bin/oowriter from openoffice.org-writer-2.0.3-7 conflicted with the same file in openoffice.org-writer-2.0.3-5.

so the i386 and x86_64 packages weren't at the same patch version, and yum correctly refused to install two different states of the distro at once on the same system (ie the mirrors the poster used where in the middle of a sync and not in consistent state - happens very often on the devel branch)

Had the poster waited some time for the mirror sync to finish he wouldn't have had any error

> 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 you have the i386 package installed it will update it to i386, if you have x86_64 it will update it to x86_64, if you have both it will update both

What won't happen is two mysqld executables on the system, and rpm will only install the x86_64 file if both packages are installed.

As I wrote, nothing to see there, Fedora multilib support works, and the original comment is pure FUD.

Misguided

Posted Jul 14, 2006 12:14 UTC (Fri) by incase (subscriber, #37115) [Link]

> The article says the error message was:

> /usr/bin/oowriter from openoffice.org-writer-2.0.3-7 conflicted with the
> same file in openoffice.org-writer-2.0.3-5.

> so the i386 and x86_64 packages weren't at the same patch version, and yum
> correctly refused to install two different states of the distro at once on
> the same system (ie the mirrors the poster used where in the middle of a
> sync and not in consistent state - happens very often on the devel branch)

While this is true for the case the original poster described, it isn't always the case. I've seen files conflicting between different packages (i.e. from different source), which were playing along nicely before.

> Had the poster waited some time for the mirror sync to finish he wouldn't
> have had any error

Yeah, possibly. However, if this happens, the mirrors are obviously not working correctly. The correct way to mirror is:
1) Download new packages
2) Download/create new index
3) Remove obsoleted packages
If mirrors would follow that route, it should be impossible to get packages from the same soure out of sync (like it happened here). It seems the fedora mirrors aren't working that way. I'm not sure wether that is a flaw inherent to the way fedora (or other rpm based distros) work or just a flaw in the specific mirrors the author used.

>> 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 you have the i386 package installed it will update it to i386, if you
> have x86_64 it will update it to x86_64, if you have both it will update
> both

I sure hope that this is the case.

> What won't happen is two mysqld executables on the system, and rpm will
> only install the x86_64 file if both packages are installed.

Ah yes, and what happens in the case I described? Will rpm fullfil the mysql dependency of the i386 package by the x86_64 mysql package? Or to take a different example:

Package A contains a binary perl module, and thus depends on perl from the same architecture. Now let's say that it only exists for i386 (because the code is not 64bit clean or whatever). Package B is available for all arches (i.e. is arch-independent) but depends on A. The system is x86_64 and has the x86_64 perl package installed with various addon modules (binary and arch-indep ones). If I want to install B, what happens? Does rpm replace the whole perl tree including all those binary modules with the i386 version? Does it install a second perl binary? Or does it refuse to do anything?

> As I wrote, nothing to see there, Fedora multilib support works, and the
> original comment is pure FUD.

You repeated that, yet you didn't explain how it works even though I asked.

Regards,
Sven

Misguided

Posted Jul 14, 2006 13:00 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

> While this is true for the case the original poster described, it isn't
> always the case. I've seen files conflicting between different packages
> (i.e. from different source), which were playing along nicely before.

so what? broken packages happen (especially 3rd-party broken packages) and rpm correctly protects you from then

> Yeah, possibly. However, if this happens, the mirrors are obviously not
> working correctly.

To have a lot of mirrors you have to accept most of them will only use rsync/http sync/ftp sync to get your files

> Ah yes, and what happens in the case I described ?

rpm will install the packages you give it on the CLI is they are consistent. Both arches if you ask it to install both, single arch otherwise.

When resolving deps, yum follows this algorithm
- if the dep is auto-tagged with a specific arch (dynamic library...) will install whichever package provides the lib with the correct arch
- if the dep is a package name or a file in /usr/bin, if the package is already installed it will update it (using whichever package arch already exists on the system). If the package is not installed, will propose both arches

yum will *never* remove a full arch tree of already installed packages like apt likes to do. It will add a new arch tree if necessary, and warn about conflicts if needed.

This is all rpm and yum multilib 101, I have the distinct feeling you are trying to make me lose my time and temper till you can declare Fedora+rpm+yum is terminally broken, dist foo is way better. So this is my final message on the subject. You want to know more, ask on Fedora lists or install Fedora on a partition.