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 revisited. 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 $? > 0 > > 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 <snip> > 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 $? > 0 > > 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 <snip> And yes, that's the *really* annoying bug. It is known: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209306 One other known 64 bit RPM bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128622 Hope this helps, James. -- 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
