Recent Features
| |||||||||||||
MisguidedMisguidedPosted Jul 13, 2006 8:25 UTC (Thu) by nim-nim (subscriber, #34454)In reply to: Misguided by elanthis Parent article: The end of the multiarch era?
I'm afraid what's pathetic there is your misunderstanding of how multiarch works in Fedora, and before FUD-ing on another distro you could had least have taken the time to check what you were writing.
Hint: Fedora does indeed behave like you write it should, hand has from the first day.
(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
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).
> - Fedora will not install by default duplicate versions of everything
True. However:
> - rpm will silently clobber binaries in /usr/bin and friends(this is the
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,
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
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
> so the i386 and x86_64 packages weren't at the same patch version, and yum
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
Yeah, possibly. However, if this happens, the mirrors are obviously not working correctly. The correct way to mirror is:
>> Which means that a package A of arch i386 depending on mysql-server will
> if you have the i386 package installed it will update it to i386, if you
I sure hope that this is the case.
> What won't happen is two mysqld executables on the system, and rpm will
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
You repeated that, yet you didn't explain how it works even though I asked.
Regards,
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
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
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.
|
|||||||||||||