Your editor, having a distinct masochistic streak, runs several different
computers, each with a different Linux distribution. For added pain, most
of them run the bleeding-edge, development version of their particular
distribution. As a result, surprises
are, well, not particularly surprising. Even so, your editor's x86-64
system running Fedora development (the distribution formerly known as
"Rawhide") managed to raise some eyebrows recently - and the news was not
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
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
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.
to post comments)