Description of problem: binutils-2.19.51.0.14.1.fc11 went into the fedora updates for x86_64 but i586 is still at 2.19.51.0.2.17.fc11. This prevents yum from updating binutils when both architectures are installed. Here's my yum info binutils on dump and I also verified on download.fedora.redhat.com that i586 version is missing from the updates location: Name : binutils Arch : x86_64 Version : 2.19.51.0.14 Release : 1.fc11 Size : 9.0 M Repo : installed From repo : updates Summary : A GNU collection of binary utilities URL : http://sources.redhat.com/binutils License : GPLv3+ Description: Binutils is a collection of binary utilities, including ar (for : creating, modifying and extracting from archives), as (a family of : GNU assemblers), gprof (for displaying call graph profile data), ld : (the GNU linker), nm (for listing symbols from object files), : objcopy (for copying and translating object files), objdump (for : displaying information from object files), ranlib (for generating : an index for the contents of an archive), size (for listing the : section sizes of an object or archive file), strings (for listing : printable strings from files), strip (for discarding symbols), and : addr2line (for converting addresses to file and line). Available Packages Name : binutils Arch : i586 Version : 2.19.51.0.2 Release : 17.fc11 Size : 3.4 M Repo : fedora Summary : A GNU collection of binary utilities URL : http://sources.redhat.com/binutils License : GPLv3+ Description: Binutils is a collection of binary utilities, including ar (for : creating, modifying and extracting from archives), as (a family of : GNU assemblers), gprof (for displaying call graph profile data), ld : (the GNU linker), nm (for listing symbols from object files), : objcopy (for copying and translating object files), objdump (for : displaying information from object files), ranlib (for generating : an index for the contents of an archive), size (for listing the : section sizes of an object or archive file), strings (for listing : printable strings from files), strip (for discarding symbols), and : addr2line (for converting addresses to file and line).
The primary download site for Fedora contains the update: $ ftp -n download.fedora.redhat.com Trying 209.132.176.221... Connected to download.fedora.redhat.com (209.132.176.221). 220 Fedora FTP server ready. Storage Provided by NetApp. All transfers are logged. [no EPSV] ftp> user (username) ftp 331 Please specify the password. Password: 230 Login successful. ftp> cd /pub/fedora/linux/updates/11/i386 250 Directory successfully changed. ftp> dir binutils* 227 Entering Passive Mode (209,132,176,221,42,32) 150 Here comes the directory listing. -rw-r--r-- 1 ftp ftp 3594333 Jul 27 12:39 binutils-2.19.51.0.14-1.fc11.i586.rpm -rw-r--r-- 2 ftp ftp 836859 Jul 27 12:39 binutils-devel-2.19.51.0.14-1.fc11.i586.rpm 226 Directory send OK. ftp> quit 221 Goodbye. Type "yum clean all" or better "rm -rf /var/cache/yum/*" and retry the command. If just the YUM cache did not get stale for some reason the chosen mirror site could get stale. This is either a bug of component "yum" or component "distribution" (virtual component for the Fedora infrastructure).
yum doesn't work the way you think it works. Please look at /etc/yum/repos.d/fedora-updates.repo. You'll see that the file's repository definitions are built on the $basearch substition. Thus the only locatoin that it looks for for updates are in the x86_64 location. Look at fedora.repo and you'll see the same thing. If you go to /pub/fedora/linux/updates/11/x86_64 on download.fedora.redhat.com you'll note that there are many many i586 packages in there as well. -rw-r--r-- 1 ftp ftp 3615349 Jul 27 12:39 binutils-2.19.51.0.14-1.fc11.x86_64.rpm -rw-r--r-- 2 ftp ftp 836859 Jul 27 12:39 binutils-devel-2.19.51.0.14-1.fc11.i586.rpm -rw-r--r-- 1 ftp ftp 848607 Jul 27 12:39 binutils-devel-2.19.51.0.14-1.fc11.x86_64.rpm for binutils alone you'll see that binutils-devel was updated, but binutils was not. if you look in /pub/fedora/linux/releases/11/Fedora/x86_64/os/Packages you'll see that there are the following binutils packages: -rw-r--r-- 4 ftp ftp 3522838 Apr 15 00:51 binutils-2.19.51.0.2-17.fc11.i586.rpm -rw-r--r-- 2 ftp ftp 3551073 Apr 15 00:51 binutils-2.19.51.0.2-17.fc11.x86_64.rpm -rw-r--r-- 4 ftp ftp 868070 Apr 15 00:52 binutils-devel-2.19.51.0.2-17.fc11.i586.rpm -rw-r--r-- 2 ftp ftp 915755 Apr 15 00:52 binutils-devel-2.19.51.0.2-17.fc11.x86_64.rpm so the release repository contains all the binutils architectures but the updates repo is missing the one i586 package.
You are right with the so-called "multilib" setup. I thought you are looking at the i586-only distribution repository in the Comment 0, sorry. releng: Therefore for F11 the multilib should still list even the "binutils" binary component just for the backward compatibility. Thanks for the bugreport. Rawhide (=F12) fortunately no longer contains "binutils" as multilib. Only "binutils-devel" makes sense as multilib which is correctly listed for Rawhide. And you should `rpm -e binutils.i586' on your system as it will workaround the problem for you, make the updates download smaller and it will have no functionality effect.
I wasn't entirely clear in my initial comment either as to what I meant (i586 missing in x86_64 repository) so apologies on my side as well. I did remove binutils.i586 for now, but at some point, oracle (either 10g or 11g) required the 32-bit binutils (binutils-devel was not enough) to install which is why i had it installed. Although it's possible that it didn't actually NEED the i586 package and I just started pulling everything in from under the sun until it worked. The Oracle installer is kinda ugly :). Anyways, thanks for looking into this, given the F12 changes, I can understand now why this was missing from the x86_64 repository.
Eew. This is going to need some thought, for how to properly obsolete the older binutils.
Isn't this what the whitelist/blacklist stuff in comps is for?
That's useful during distro upgrades, but this is happening within a release, not between releases. (as to why this kind of change is happening in a release, that's a whole different ... discussion)
in case it helps. I've confirmed on 3 other redhat and fedora systems that 32-bit binutils was not required to install oracle and I just mistakenly pulled it in when trying to resolve dependencies on my personal workstation. So unless there's a wider problem with removing binutils.i586 from updates, AFAIK, this bug is resolved for me by uninstalling binutils.i586 since I never actually needed. Are there any legitimate cases where one might need multilib binutils?
Jesse - would 'Obsoletes: binutils < <whatever>' work?
I seem to recall that obsoletes don't cross arches, but I would have to confirm that with Seth. I'm adding him to the CC list.
*** Bug 520533 has been marked as a duplicate of this bug. ***
Given that we've don't seem to have pushed the main binutils package as an official update, AFAIK, I don't think there's anything we need to do here.