Misguided [LWN.net]

Misguided

Posted Jul 13, 2006 18:16 UTC (Thu) by nim-nim (subscriber, #34454)
In reply to: Misguided by incase
Parent article: The end of the multiarch era?

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

(Log in to post comments)

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.