parted package on x86_64
fedora at aprilcottage.co.uk
Wed Dec 13 22:45:42 UTC 2006
Curtis Doty wrote:
> On fresh x86_64 FC6, it installs both parted.i386 and parted.x86_64. My
> first question is why? There don't appear to be any dependencies on either
> specific arch. Although, I do understand that parted is a general good
> thing to have in Core. Why not just the 64-bit package?
As you know, one of the features of the x86-64 architecture is that it
can also run 32 bit x86 programs. Since FC6 (when OpenOffice went 64
bit) this isn't really needed for Fedora packages, but many more obscure
or more commercial programs don't have (working) x86-64 versions. So
Fedora attempts to provide the infrastructure to support them.
Unfortunately, 32 bit programs can't link against 64 bit libraries.
Therefore, Fedora tries to ship as many "library" packages as possible
in 32 *and* 64 bit versions.
So no, nothing in Fedora requires parted.i386. It's provided in case
something not in Fedora requires it.
You could have the 32 bit version in Extras, but the current
build-system would make that *very* difficult. The split between Core
and Extras is probably going away for Fedora 7, so this might be
As for why it's installed by default, yum will install both
architectures unless you tell it otherwise, and the Fedora developers
decided not to tell it otherwise. (This has been debated -- there were
calls for a "32 bit compatibility" group when you're selecting packages
to install, but it didn't make FC6).
> Rpm verify produces the usual annoying uselessness from multi-arch
> installs. What's interesting is no errors with the 64-bit package:
> # rpm -V parted.x86_64 ; echo $?
> But loads of failures with the 32-bit package:
> # rpm -V parted.i386
> S.5....T /sbin/parted
> S.5....T /sbin/partprobe
> .......T d /usr/share/info/parted.info.gz
> .......T /usr/share/locale/ca/LC_MESSAGES/parted.mo
> Silly and confusing how rpm on Fedora seems to give ownership of the same
> file to conflicting packages, but still allow them to be co-installed
> automatically from anaconda. Why does this happen for quite a number of
> FC6 packages?
Well, if you're going to have 32 bit packages and 64 bit packages
installed at the same time, you've only got a few options.
You could insist that all the files in the standard 64 bit version have
different names (or paths) to the standard 32 bit versions. That's a
non-starter -- scripts and user knowledge then isn't portable, and the
64 bit OS is a different OS.
You could try installing the 32 bit packages in a separate directory
tree and using chroot to get everything working. That's one of the
options Debian and Ubuntu give you. But it means you have to do
something special to run 32 bit programs, and then all the rest of your
files aren't where you expect them to be. It's workable, but you have to
work at it. It also means that you potentially have two sets of
configuration files to keep in sync.
Or there's the other option Debian and Ubuntu give you -- make the 32
bit packages dependent on the 64 bit ones, and only contain the 32-bit
libraries. You could potentially take that a lot further than they do --
have the 32-on-64 packages be created automatically for all appropriate
packages. You still would have problems if for any reason (e.g. Firefox
and plugins) you really wanted the 32 bit version and not the 64 bit
one, *and* wanted yum to give you updates from the right repo.
Or you can do the "32-on-64" stuff in the package manager -- put 32 bit
libraries in */lib, 64 bit in */lib64, and if both are installed prefer
the 64 bit programs. Non-executable files should be the same anyway, and
if so it doesn't matter which one gets installed. That does mean that
the 32 bit version and the 64 bit version have to remain in sync, but
that's not a hardship in practice. It means that the 32 bit versions
*are* the same as from the 32 bit repo, so you get maximum flexibility
to mix and match. And that's what Fedora does.
So you change the rules a bit. Otherwise-identical 64 bit and 32 bit
packages don't conflict, and files can belong to multiple packages (as
long as they've got the same contents and metadata). And normally it
does the right thing.
> It renders rpm -V utterly useless due to extremely high
> noise to signal ratio.
Pipe it through fgrep -v .......T
It has to be said that there are a number of bugs in RPM that should
really be fixed, but what's currently regarded as "RPM upstream" (the
maintainers responsible for the RPM package itself) have been taking it
in directions that Fedora (and other distros) isn't sure it wants to go.
There has been talk, but no action yet, on forking RPM.
> Anyways, that's not my bug. After removing just the 64-bit package
> (for "fun" just now), *very* wacky and curious results are found:
> # rpm -e parted.x86_64
> # rpm -V parted.x86_64 ; echo $?
> WTF? It still verifies clean. And check this:
OK, yes, that is a weird bug. If you check, you'll see that even if
there's never been an i386 version of a package installed,
rpm -V package.i386 doesn't moan as long as there is a 64-bit package
with the same name.
> # rpm -V parted.i386 ; echo $?
> prelink: /sbin/parted: Could not find one of the dependencies
> prelink: /sbin/parted: at least one of file's dependencies has changed
> since prelinking
> S.?....T /sbin/parted
> prelink: /sbin/partprobe: Could not find one of the dependencies
> prelink: /sbin/partprobe: at least one of file's dependencies has changed
> since prelinking
> S.?....T /sbin/partprobe
> missing /usr/share/doc/parted-1.8.0
> missing d /usr/share/doc/parted-1.8.0/API
And yes, that's the *really* annoying bug. It is known:
One other known 64 bit RPM bug:
Hope this helps,
E-mail: james@ | Practically any car advert, for example, shows you that
aprilcottage.co.uk | if you buy this car you will get so lost that you end up
| parked (well, no. The word here is "stuck") on a mountain
| in Monument Valley. -- Telsa Gwynne
More information about the users