The end of the multiarch era?
One of the endearing features of Fedora Development on x86-64 is that the chances of running "yum update" successfully at any given time tend to be less than 50% - especially if the system has any packages from Extras installed. Between dependency hassles and travel, this particular system had not been updated in some time. Your editor finally broke down, deleted a few packages which were blocking the update, and set off on what looked like a plausible attempt to catch up to the leading edge. After a quick check of the current backups, your editor fired off the "yum update" command.
After thinking at length and forcing every other process out to swap in the way only yum can do, the word came back: the system could be updated, at the cost of downloading some 420 packages. Installing that many potentially unstable packages onto an important system requires a significant girding of loins - a state of preparedness which can be difficult to maintain while waiting for all those packages to download from the (not particularly speedy) mirror network. Once that process completed, yum had another long think, then announced a file conflict: /usr/bin/oowriter from openoffice.org-writer-2.0.3-7 conflicted with the same file in openoffice.org-writer-2.0.3-5.
Yum, of course, refused to update the system. That much is understandable, but its subsequent decision to delete all 420 downloaded (but uninstalled) packages can only be seen as gratuitous and mean-spirited.
To the uninitiated, it would appear that yum is complaining about a package conflicting with itself. Experienced Fedora x86-64 users, however, recognize the problem immediately: the x86-64 and i386 versions of the same package are refusing to play well together. This was, thus, your editor's introduction to the good news portion of this exercise: Fedora Development now has a native 64-bit version of OpenOffice.org. All that was necessary was to manually clear out the old, 32-bit version and rerun the update (in the process re-downloading all 420 packages). Some quick tests show that the 64-bit OpenOffice.org appears to work, and your editor can now begin the task of cleaning out the vast pile of 32-bit libraries that OpenOffice.org traditionally dragged onto the system with it.
While a full assessment is yet to be made, it is your editor's opinion that OpenOffice.org was the last 32-bit application running on this 64-bit system. That means that the whole multi-architecture support infrastructure needed to run 32-bit programs can now go away, and it will not be a moment too soon.
Multiple architecture support seems like a nice idea. With a bit of work, a system can transparently run binaries compiled for a different architecture. That can be good for system migrations, and it can make it easier to grab precompiled (or proprietary) applications from elsewhere and quickly make use of them. It allowed your editor to run OpenOffice.org even though that application was not able to build and run properly on your editor's system.
But multiple-architecture support can be an administrative nightmare. Keeping multiple versions of the same package synchronized can be a challenge, and, if the package creators are not careful, they will not mix well together. It is amazing how many libraries must be dragged along for both architectures; the inevitable crufting up of the system happens much more quickly. Your editor never asked to have two versions of MySQL, CUPS, gphoto, GTK2, PAM, etc., but they showed up anyway. And one can only hope that whoever came up with /lib64 has had the opportunity to spend much time in a solitary cell with a bunch of applications using old configure scripts.
In a world where applications cannot be rebuilt, multiarch support might be
a life saver. But, in a free software environment, we should not need it.
We can build our programs to run on the target's native architecture, and
need not saddle ourselves with the overhead and hassles of multiarch
support. Your editor is looking forward to cleaning up the some 140 i386
packages still on this system - they should not be needed anymore.
Posted Jul 13, 2006 2:57 UTC (Thu)
by loening (guest, #174)
[Link] (1 responses)
I'm currently running i386 Firefox (on an x86_64 Fedora system). This is because there are certain web sites (e.g. the Daily Show) that regretably require Flash... and Macromedia currently only has a i386 Firefox plugin.
Will x86_64 Firefox be extended to allow running i386 plugins? Is there a free software version of Flash that's worth trying?
Posted Jul 13, 2006 6:04 UTC (Thu)
by AnswerGuy (guest, #1256)
[Link]
You might want to try:
NSPluginWrapper which is, a wrapper that can run 32-bit processes under your 64-bit Netscape/Mozilla (or Firefox, of course).
Posted Jul 13, 2006 3:20 UTC (Thu)
by elanthis (guest, #6227)
[Link] (12 responses)
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.
Posted Jul 13, 2006 7:24 UTC (Thu)
by evgeny (subscriber, #774)
[Link] (2 responses)
I have this all the time; why does the server need to know anything about what it NFS-exports?!
> So all of your open source apps are now 64-bit clean, hmm?
Well, of course not right now; but that was the Jon's assertion that the amount of free software that doesn't compile on any reasonable arch should be decreasing with time (and it is; OO is one of the last dinosaurs). The very idea of multiarch is because there are CPUs supporting more than one target instructions; in turn, this happened mostly because of the vast amount of closed-source software which the chipmakers wanted to support.
> Just because Fedora sucks rocks at multi-arch doesn't mean that multi-arch is dead, is unfeasible, or not useful. Let some of the competing, much better thought out alternatives rise up.
Of course, Gentoo rules here (IMHO, it does also in any other comparison with FC).
Posted Jul 18, 2006 16:43 UTC (Tue)
by hazelsct (guest, #3659)
[Link] (1 responses)
> I have this all the time; why does the server need to know anything about what it NFS-exports?!
So that one can use a package manager on the PPC server to install the amd64 and ARM packages and serve them all up to the various clients properly. Imagine being able to "apt-get update && apt-get dist-upgrade" and have all three arches upgrade at once.
(Can't do it in a chroot because the binaries won't run -- not to mention the wasted space of the duplicated -common packages.)
Posted Jul 18, 2006 17:27 UTC (Tue)
by evgeny (subscriber, #774)
[Link]
There is no reason why a package manager shouldn't be able to deal with packages for another arch; this has nothing to do with the multiarch OS support. Did you mean perhaps the multiarch support for your favorite package manager?
> Imagine being able to "apt-get update && apt-get dist-upgrade" and have all three arches upgrade at once.
Heh, you've got quite a bit of imagination... Not to mention many technical details why it'd never work correctly (at least with the current apt), are you serious you want to have the _same_ OS on the server and clients?! And what about _several_ different thin client images? (In my case, a RH-7.3 box simultaneously serves releases of Slackware, Ubuntu, and Knoppix thin clients; users tend to be picky about their favorite distro...).
> (Can't do it in a chroot because the binaries won't run
There is no need to use chroot for that. Just give one NFS client (e.g. your own workstation) a temporary r/w acces and do all the upgrades from it.
> -- not to mention the wasted space of the duplicated -common packages.)
So now you're talking about NFS-exporting the root file system of the server?!
C'mon, NFS has a notorious track record of security holes (and is inherently insecure anyway). And, 90% of the client disk space would be due to the GUI apps which shouldn't be installed on the server.
Posted Jul 13, 2006 8:25 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (6 responses)
Hint: Fedora does indeed behave like you write it should, hand has from the first day.
Posted Jul 13, 2006 11:42 UTC (Thu)
by paulj (subscriber, #341)
[Link] (5 responses)
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.
Posted Jul 13, 2006 13:30 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (4 responses)
- 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
Posted Jul 13, 2006 16:12 UTC (Thu)
by incase (guest, #37115)
[Link] (3 responses)
> - 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,
Posted Jul 13, 2006 18:16 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (2 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)
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.
Posted Jul 14, 2006 12:14 UTC (Fri)
by incase (guest, #37115)
[Link] (1 responses)
> /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,
Posted Jul 14, 2006 13:00 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link]
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.
Posted Jul 16, 2006 19:45 UTC (Sun)
by komarek (guest, #7295)
[Link]
I've never even seen a 32-bit clean system, so I'm not sure this is the right question. A more useful question might be "So now all you open source apps run tolerably well when compiled for 64-bit architectures, hmm?" The only problem I see with this question is that it drains the vitriol.
ANSI C89 all the way! Or C99 if you like to live on the edge.
-Paul
Posted Jul 20, 2006 15:19 UTC (Thu)
by renox (guest, #23785)
[Link]
If we look at the history, x86-64 seems to be the 'last' architecture for a long time..
Posted Jul 13, 2006 4:13 UTC (Thu)
by skvidal (guest, #3094)
[Link] (14 responses)
Or you could just call it a bug rather than attributing it to some kind of malice. Read the docs for this feature. It's called 'keepcache' and was specifically mentioned in the fedora core 5 release notes. It was added in yum 2.6.X in order to keep people's /var/ partitions from filling up. We've got a bug report open about in some situations it clearing the cache even if the packages did not successfully install. However, we've not been able to replicate it which makes fixing it difficult.
If you do not want i386/i686 packages then simply add:
to your yum.conf under [main]
and if you want to remove all the i386 or i686 packages from your system run:
yum remove \*.i386 \*.i686
and that will do it.
I realize this was an editorial but your snarky and caustic tone isn't terribly helpful. I can't help but notice a complete absence of bug reports from you on the problems you've experienced and yet you've found time to be hateful on your website. That's unfortunate.
-sv
Posted Jul 13, 2006 4:51 UTC (Thu)
by charris (guest, #13263)
[Link] (4 responses)
Geez, lighten up, skvidal. Hateful, hateful? Are you going to stamp your little foot, slam the door, and burst into tears?
I thought it was funny.
Posted Jul 13, 2006 6:27 UTC (Thu)
by pjm (guest, #2080)
[Link] (3 responses)
Posted Jul 13, 2006 8:21 UTC (Thu)
by drag (guest, #31333)
[Link] (1 responses)
Obviously the guy isn't that pissed about it or he would of stopped using the software all together.
Plus it WAS funny. Made me laugh.
Remember (even if you have to say it to yourself over and over again to remind yourself):
ALL SOFTWARE SUCKS.
Posted Jul 13, 2006 18:21 UTC (Thu)
by pimlott (guest, #1535)
[Link]
Posted Jul 13, 2006 5:02 UTC (Thu)
by pimlott (guest, #1535)
[Link] (1 responses)
Posted Jul 20, 2006 17:16 UTC (Thu)
by rvfh (guest, #31018)
[Link]
AND he made it very clear that he was running a cutting edge
development version, so bugs are not only excusable, they're
expected!
Posted Jul 13, 2006 5:40 UTC (Thu)
by Los__D (guest, #15263)
[Link]
I realize this was an editorial but your snarky and caustic tone isn't terribly helpful. But very, very funny.
Posted Jul 13, 2006 6:19 UTC (Thu)
by AnswerGuy (guest, #1256)
[Link]
It was the funniest line in the whole article.
My came in to see what I was chuckling about and I read the hole lead in and she's laughing now.
(Personally I think it's pretty bone headed to default to empty a cache when a process is quitting due to an error. The most common usage scenarios would entail attempting to fix the error and re-run the process, DUH!
If I was implementing something like this I'd make the configuration take a list of flags, percentages, and numeric values (all optional). So you could say: Clean-up: on success; 15%: 800M which would mean: "clean up only if the whole process was successfull (the RPMs are all installed now), or the file systems has less then 15% or 800MiB of free space available (in case I had some real need to build ISO images under that fs that I feel are more pressing than the risk to my cache). Other flags might be: obsolete, never, always (obsolete meaning that we clear the cache of any files for which we've already got an updated version). (Some peope might question why I'd have a percentage and a number --- answer is I might want to have a config that I can use across lots of hosts and I may not want to have to do funning template perl -pi -e 's/..../.../;' stuff to fiddle with calculated sizes).
Posted Jul 13, 2006 10:15 UTC (Thu)
by brwk (guest, #6849)
[Link]
In our environment we have a locally grown RPM (which works on RHEL, SuSE and FC), that tweeks litterally dozens of config files to change all manner of things from /etc/yum.conf, /etc/nsswitch.conf, /etc/yum.repos.d, /etc/X11/gdm.conf and so on. However, this has been grown over the last fifteen years by a team that has over a hundred man years experience in managing Unix/Linux systems. It seems to me that there needs to be a mid-point between the "one size fits all" of a distribution default and the "ultra-tailored" environment that experienced sysadmins can create. Maybe a number of "system profiles" that can be selected: "low intervention" (ie cleans up as much as possible), "well resourced" (ie caches can be kept around, etc) and "paranoid" (ie keeps everything for rollback, etc).
Regards, Bevis.
Posted Jul 13, 2006 13:08 UTC (Thu)
by corbet (editor, #1)
[Link] (3 responses)
1) I'm running development distributions; I expect strange things to happen every now and then. One can only laugh at them, that's what I tried to do.
2) I do get onto the fedora-test list occasionally when things go really wrong. I have also occasionally put things into bugzilla. I have certainly posted about the challenges of keeping multiarch systems current in the past (though not recently).
Believe it or not, this article was not an attack on Fedora - it was a discussion of how it's getting better.
Posted Jul 13, 2006 14:58 UTC (Thu)
by cventers (guest, #31465)
[Link] (2 responses)
That's how you know you've written a good article.
PS: I think Multiarch support is important. But good article! :)
Posted Jul 13, 2006 20:32 UTC (Thu)
by dmantione (guest, #4640)
[Link] (1 responses)
Posted Jul 18, 2006 4:19 UTC (Tue)
by xoddam (subscriber, #2322)
[Link]
Posted Jul 13, 2006 5:29 UTC (Thu)
by xorbe (guest, #3165)
[Link]
Hahaha! Sorry... I got tired of the Mandrake tool doing
Posted Jul 13, 2006 9:28 UTC (Thu)
by dale77 (guest, #1490)
[Link]
I too hope multiarch will go west, although I currently run 32bit soft on
Posted Jul 13, 2006 10:32 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Ones which spring immediately to mind include MIPS64 and SPARC64. On such platforms, the only stuff which tends to be 64-bit is kernel code and things which truly benefit (mathematical stuff, stuff which needs huge address spaces like perhaps image processing software, and things which really benefit from the extra size of words, like Emacs). Everything else is left 32-bit. (As others have commented, though, the only things which ever need two copies of themselves installed are *libraries* and in rare circumstances a few header files; the rest should have only one arch's version installed.)
So multiarch continues to be useful.
Posted Jul 13, 2006 11:56 UTC (Thu)
by dmantione (guest, #4640)
[Link] (6 responses)
Posted Jul 13, 2006 13:09 UTC (Thu)
by kleptog (subscriber, #1183)
[Link] (3 responses)
All Linux users befefit greatly because of the backward compatibility of
the kernel. You can simply upgrade your kernel without fear of breaking
your system. No such compatibility exists for many user space
applications. I'm quite sure most readers here have seen the famous glibc
missing symbol messages.
OTOH, glibc has backward compatability going back several versions. There are multiple versions of fdopen for example, to make sure programs get exactly the version they compiled with. The kernel doesn't even try to provide that kind of compatability.
Lastly /lib64 was a very smart choice.
In that I agree with you, multiarch is the way of the future. We're just not there yet.
Posted Jul 13, 2006 14:09 UTC (Thu)
by dmantione (guest, #4640)
[Link] (2 responses)
Posted Jul 13, 2006 18:11 UTC (Thu)
by kleptog (subscriber, #1183)
[Link] (1 responses)
Having the same userspace work for all versions of 2.6 kernels is just about impossible.
Posted Jul 13, 2006 19:11 UTC (Thu)
by dmantione (guest, #4640)
[Link]
Posted Jul 13, 2006 13:57 UTC (Thu)
by wookey (guest, #5501)
[Link] (1 responses)
Sorry - that's not true. It's a very limiting choice. It assumes there is only one case where you might want more than one arch present - mixing 32 bit and 64 bit binaries of the same(ish) CPU architecture. The multi-arch concept is much more widely useful than that, as a couple of people have mentioned above, and described in some detail at http://lackof.org/taggart/hacking/multiarch/.
It can help with things like cross-building (somewhere to put target-system binaries (e.g. ARM) needed during the build process which you are going to run using an emulator such as QEMU. Mixing glibc and uclibc, mixing big-endian and little endian code, mxing OS stuff (having some windows programs installed on your linux system), etc. A properly-designed multi-arch system make all sorts of interesting things possible.
Debian is implementing a scheme which allows arbitrary mixes of architectures:
Posted Jul 13, 2006 14:14 UTC (Thu)
by dmantione (guest, #4640)
[Link]
Posted Jul 13, 2006 13:46 UTC (Thu)
by jnelson (guest, #6693)
[Link] (1 responses)
Smart has vastly better multi-arch support and has better dependency resolution algorithms.
I use smart on SuSE after having experimented with apt (terrible multi-arch support) and yum (all of the problems you describe above).
Posted Jul 20, 2006 8:47 UTC (Thu)
by quintesse (guest, #14569)
[Link]
- occasional cyclic upgrades/downgrades where running smart multiple times will first upgrade a package and then downgrade it again, ad infinitum
- SLOW for large upgrades, forget about upgrading from FC5 to FC6 using smart
NB: For upgrades like that the advise seems to be: apt-get dist-upgrade and smart afterwards to fix any problems. And if you tried to do it using yum, well the mess is entirely your own fault.
Posted Jul 13, 2006 18:59 UTC (Thu)
by lindahl (guest, #15266)
[Link]
PathScale's compiler, for example, is ~ 2x faster on x86-64 as a 32-bit app. And there are 4 parts of the SPECint benchmark suite which are generally faster as 32-bit on x86-64. On other architectures, a much larger proportion of programs are faster as 32-bit apps, since x86-64 has more registers for 64-bit apps, but other architectures generally don't.
-- greg
Posted Jul 13, 2006 21:43 UTC (Thu)
by garloff (subscriber, #319)
[Link]
But it's strange to read that multiarch support is a pain for him.
I really never had such trouble. If I compile code myself (which I
Biarch is working and works well. It allows you to run apps that for
Posted Jul 14, 2006 7:22 UTC (Fri)
by ymmv (guest, #4375)
[Link] (1 responses)
Your operating environnement was working nicely, but your 64bit application refused to load and run.
Suppose also you have to package some low level library for Solaris (or any other double arch OS): you have to compile it twice, test it twice, with different directory schemes, and then package. A real mess :(
Tru64/Digital Unix/OSF/1 approach of having everything 64bit was much more simple to administer, at the expense of some memory and disk to hold these 64bit binaries. Peanuts nowadays.
So please, keep these free and open OS as mono-architecture.
Posted Jul 14, 2006 11:53 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Jul 19, 2006 16:02 UTC (Wed)
by kolyshkin (guest, #34342)
[Link]
Still, I agree it would be much better to remove the packages only if installation succeds, not in any case.
Posted Dec 3, 2006 17:59 UTC (Sun)
by Aukcje (guest, #41946)
[Link] (1 responses)
Posted Jun 8, 2007 12:47 UTC (Fri)
by cooles (guest, #45682)
[Link]
Any comments on an x86_64 compatible flash plugin?The end of the multiarch era?
nspluginwrapper
Jim Dennis
The author essentially is complaining "Fedora's pathetic RPM 'support' of multi-arch blows chunks" and thus he concludes that multi-arch is doomed.Misguided
> Imagine, for example, having a server which exports NFS-mounted file systems to thin clients.Misguided
> > Imagine, for example, having a server which exports NFS-mounted file systems to thin clients.Misguided - NOT!
> So that one can use a package manager on the PPC server to install the amd64 and ARM packages and serve them all up to the various clients properly.Misguided - NOT!
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.Misguided
Misguided
To make it quick because I have other things to do :Misguided
> To make it quick because I have other things to do :Misguided
> 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)
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.
> 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
> 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
sven
> However, this is precisely the problem with RPM and file conflicts. In the > original article, the i386 version of OOo conflicted with the AMD64Misguided
> version because they contained different versions of the same file (or at
> least that seems to be the reason here).
> pull in the i386 version of mysql-server even though the AMD64 version of
> mysql-server is already installed
> The article says the error message was:Misguided
> same file in openoffice.org-writer-2.0.3-5.
> 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)
> have had any error
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.
>> pull in the i386 version of mysql-server even though the AMD64 version
>> of mysql-server is already installed
> have x86_64 it will update it to x86_64, if you have both it will update
> both
> only install the x86_64 file if both packages are installed.
> original comment is pure FUD.
Sven
> While this is true for the case the original poster described, it isn'tMisguided
> always the case. I've seen files conflicting between different packages
> (i.e. from different source), which were playing along nicely before.
> working correctly.
- 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
> So all of your open source apps are now 64-bit clean, hmm?Misguided
>what happens when the next architecture switch happens?Misguided
Quote:The end of the multiarch era?
Yum, of course, refused to update the system. That much is understandable, but its subsequent decision to delete all 420 downloaded (but uninstalled) packages can only be seen as gratuitous and mean-spirited.
End Quote.
exclude=*.i386 *.i686
...and yet you've found time to be hateful on your website.
The end of the multiarch era?
I think it reasonable to ask people to file bug reports about things they don't like before complaining so publicly.bug reports and editorials
It's just a article. People are allowed to bitch and moan if they feel like it and there isn't any single thing wrong with it as long as they aren't being slanderous.bug reports and editorials
(yes, even the Free stuff).
Or as the prophet sayest, "Thou shalt know by your heart that all software sucks."
bug reports and editorials
The end of the multiarch era?
I realize this was an editorial but your snarky and caustic tone isn't terribly helpful.
But terribly entertaining. That counts for something, right? Seriously, there's nothing to gain by getting defensive or self-righteous about problem reports, no matter their shortcomings in tone or content. If Jon had this problem, there are probably a hundred users with worse experiences who got too frustrated or overwhelmed to say anything. Swallow your pride and thank him for the feedback.
The end of the multiarch era?
The end of the multiarch era?
Survey Says! ....
JimD
While I understand Seth's angst at the negative comments against yum, I think it's one of those difficult situations where the software author has gone a good job and it is the software distribution's defaults that causes a problem in specific cases.The end of the multiarch era?
Whoa, Seth, sorry you took it so personally. Certainly wasn't my intent. A couple of things:
The end of the multiarch era?
25 comments, many of them firey :)The end of the multiarch era?
If a president holds a speech that it would be a good idea to disband the The end of the multiarch era?
army that will cause a lot of discussion. However, that does not mean
it is necessarily a good speech.
that there is a difference between an editor and a Commander in Chief. Which reinforces only
Powerful interests don't need to 'hold speeches' when they 0wn the
network media and the voting machines.
> That much is understandable, but its subsequent decisionThe end of the multiarch era?
> to delete all 420 downloaded (but uninstalled) packages
> can only be seen as gratuitous and mean-spirited.
weird things like that, so I mirror the whole dang thing,
and I have some small custom scripts that figure out what
rpms have upgrades available, and I let urpmi loose on
them from my local mirror. Sure, download is looong, but
that runs on a weekend and not on my watch. Been working
for years!
Nice article, particularly that mean-spirited view of yum.The end of the multiarch era?
my Athlon64, purely because I don't want the grief of 64-bit bugs that
don't afflict 32 bit world. Things like the aforementioned flash problem
are something I just don't want to deal with.
Multiarch may be unnecessary (in the long run) on x86-64, but it will always be needed on other platforms, on which the common case is to keep things 32-bit because the only difference between 64-bitness and 32-bitness on those platforms is alignment constraints, accessible address space, and the sizes of pointer and integral types. Going 64-bit thus has disadvantages (reduced speed and more cache misses, increased memory usage and disk space consumption) that more than counter the advantages.The end of the multiarch era?
I couldn't disagree more with the author. Of course his reasoning is a The end of the multiarch era?
fallacy, but apparently the author disagrees with backwards compatibility
regardless wether RPM works correctly.
All Linux users befefit greatly because of the backward compatibility of
the kernel. You can simply upgrade your kernel without fear of breaking
your system. No such compatibility exists for many user space
applications. I'm quite sure most readers here have seen the famous glibc
missing symbol messages.
Sure, recompiling is a possibility for open source applications. I'm
quite confident few people have systems where they compiled all
applications themselves. Nor do I have the idea that people desire to
recompile all their application when they upgrade a library.
Lastly /lib64 was a very smart choice. It is mandated by the x86_64 ABI
http://www.x86-64.org/documentation/abi-0.96.pdf, so complain to the
authors about it.
/lib64 is based two ideas:
* It must be possible to install 32-bit RPMs on both i386 and x86_64
systems without change.
* Source code can be changed to use /lib64, binaries cannot. So, to allow
existing rpms to install on x86_64 systems, they should be able to find
their libraries in /lib.
This does not just benefit developers of closed source software, but also
any open source project that distributes binaries.
Try our Free Pascal i386 RPM and note that just magically works on your
Linux system, regardless which libc you use or wether you use i386 on
x86_64:
ftp://ftp.freepascal.org/pub/fpc/dist/i386-linux-2.0.2/rp...
That is how software is supposed to work.
Besides multiarch not just benefits the user who wants to use software,
but also the developer who wants to support both 32 and 64 bit. I wish
multiarch a long and healthy future.
The end of the multiarch era?
No, we've had a lot more breakage trouble with Glibc than with the The end of the multiarch era?
kernel. Glibc breaks compatibility within minor versions. An example of
such breakage:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90002
It is true that glibc has backwards compatibility functionality inside,
and things seem to be improving, but for Free Pascal we have had to
stay away from it, it was simply impossible to support multiple
distributions when we had libc dependencies.
Note that on Darwin & Solaris we do use libc, and as of yet we never had
any breakage.
I think you're comparing apples to oranges here. You're comparing a bug in glibc (which was fixed) to the fact that the kernel breaks backward compatability permanently in "minor" releases. devfs was removed in 2.6.13. Systems using udev won't work with kernel versions older than 2.6.15. In the middle is hotplug.The end of the multiarch era?
It was not fixed, you are confusing the _res issue with the errno issue. The end of the multiarch era?
The 1.0.10 compiler from 2003 still works on modern kernels, so we can
test:
daniel@laptop:~> cat test.pas
program test;
uses inet;
begin
end.
daniel@laptop:~> rpm -q -a|grep glibc
glibc-2.3.3-118
glibc-locale-2.3.3-118
glibc-devel-2.3.3-118
daniel@laptop:~> /usr/local/lib/fpc/1.0.10/ppc386 -n
-Fu/usr/local/lib/fpc/1.0.10/units/linux/* test
/usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0x3a2): In
function `_INET$$_$$_THOST_$$_NAMELOOKUP$STRING':
: undefined reference to `h_errno'
/usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0x40d): In
function `_INET$$_$$_THOST_$$_ADDRESSLOOKUP$THOSTADDR':
: undefined reference to `h_errno'
/usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0x742): In
function `_INET$$_$$_TNET_$$_NAMELOOKUP$STRING':
: undefined reference to `h_errno'
/usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0x79a): In
function `_INET$$_$$_TNET_$$_ADDRESSLOOKUP$LONGINT':
: undefined reference to `h_errno'
/usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0xa6c): In
function `_INET$$_$$_TSERVICE_$$_NAMELOOKUP$STRING$STRING':
: undefined reference to `h_errno'
/usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0xb37): more
undefined references to `h_errno' follow
test.pas(7) Error: Error while linking
daniel@laptop:~>
The issue was solved in the modern compilers by coding a netdb
package in Pascal, and it never gave us trouble ever again.
I think you are right about the kernel versus its system tools. However,
for applications the kernel has remained remarkably compatible. We
recently discovered that we were still using a system call that was
replaced by a more advanced one in kernel 2.0 (we are one of the older
free software projects), it still worked.
Lastly /lib64 was a very smart choice.
The end of the multiarch era?
Sure, you can generalize that /lib64 can be improved to random The end of the multiarch era?
architectures. It is even a good idea. In the meantime, Debian (and
derivates) is one of the few x86_64 distribution that cannot flawlessly
run x86 binaries. In typical Debian style, it will take years to
develop.
Considering this, /lib64 was a good choice.
Just use Smart referenced here:Just use Smart
http://labix.org/smart (it's home)
and here:
http://fedoranews.org/blog/?p=573
Agreed, smart is really good at solving strange dependencies and has so far not given me any problems. The only things that I can see wrong with it are:Just use Smart
Multiarch isn't going away. In 64-bit systems, it's frequently the case that a 32-bit executable can be much faster. Why? Programs that use a lot of pointers.The end of the multiarch era?
I agree with the editor that having OO.o finally work on x86-64 isThe end of the multiarch era?
really good news.
Does yum play strange tricks on him? Did the distributor do a poor
job with handling the biarch stuff cleanly? Did he just confuse everyone
with RPM colors?
do quite often), it's all 64bit clean. So I only need the 64bit -devel
packages. And my distributor fixed broken configure scripts 4 years
ago ...
whatever reason are not provided as 64bit binaries, and they just work.
User friendliness means that old thing continue to work. Whether it's
because it's not realistic to expect someone to recompile all the code,
or whether it is because you have pieces that are very difficult to
get fixed or whether you have some app where you don't have the sources
for does not matter. It's good not to break old stuff and still allow
to move on.
Multiarch packaging has been a failure even since the double arch Solaris.The end of the multiarch era?
The worst was when patches were available for one arch (32bit), and the supposed to be there sparcv9 binaries were not included in the patch.
All SPARC64 OSes are biarch at least, sorry (even if the 64-bit part is just the kernel, it is still there, and it is often a bit more than that).The end of the multiarch era?
Looks like nobody gave the answer on "downloading all the files again" problem. To keep the packages after downloading them, just add "keepcache=1" to [main] section of /etc/yum.conf file.The end of the multiarch era?
I'm currently running i386 Firefox (on an x86_64 Fedora system).
The end of the multiarch era?
Thanks
Aukcje
Thanks for very needed for me informations! Really thanksThe end of the multiarch era?