Misguided

Posted Jul 13, 2006 13:30 UTC (Thu) by nim-nim (subscriber, #34454)
In reply to: Misguided by paulj
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)

- 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 (guest, #37115) [Link] (3 responses)

> 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] (2 responses)

> 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 (guest, #37115) [Link] (1 responses)

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