We need a better way of selecting which packages should be available for both architectures, in a multilib system. The 'has a -devel subpackage' heuristic was a great hack for the first five minutes, and was an improvement on a hardcoded list in anaconda, but needs to be replaced with something better. It has both false positives and false negatives. The false positives wouldn't be so much of an issue if bug #235757 was fixed, but the false negatives remain. I think this needs to be marked by a tag in the binary package itself, marking it as suitable (or not) for being shipped multilib -- nothing else scales. An i386 package will appear in the x86_64 repo, or a ppc64 package in the ppc repo, only if marked for multilib.
Hm, this should probably be filed against rpm first.
It's suboptimal if we have to add a new tag to _every_ specfile, although it's certainly possible (and we've managed s/Copyright/License/' already). We might be able to come up with heuristics for it though... First, check if the binary package has files in the binary but not multilib directories like /{usr/,}{s,}bin Then, check if it has files in the multilib directories /{usr/,}lib{64,} If it has files in only one of the above, it can possibly be automatically marked as non-multilib or multilib respectively. If it has files in both, then it _must_ have an explict tag in the specfile. This actually helps us enforce the suggested solution for bug #235757 too, because packages mixing binaries and libraries will fail to build without an explicit Multilib: tag. And the recommended fix for packagers encountering that failure would be to split the package appropriately; not to just add the tag.
There are a couple of special cases here -- stuff like gdb and strace need to be shipped for the 64-bit architecture even when that's normally the 'secondary arch'. These cases are few enough that perhaps we could handle them specially in yum -- but that's not a very pretty solution. Could it be made to work if the ppc64 gdb just had something like 'Obsoletes: gdb.ppc'? Or would we want to either augment the 'Multilib' tag to indicate such a preference (along the lines of yes|no|prefer64), or add a new 'PreferredArch' tag or something?
I'm not much help as the assignee. Interested to see where this goes though.
if you write up the heuristic as a script (so I can see exactly what is involved), I'll add a RPMTAG_MULTILIB_READY boolean as a header tag extension. That basically means that the value will be whatever the result of the script returns, all packages.
This bug needs to be moved to distro (unless you want the header tag extension written) NOTABUF wrto rpm, which certainly knows diddly about -devel heuristics for shipping multilib packages.
Frankly, I'd prefer semantic tags, like 'development', 'runtime library', 'debugging tool', etc.; then there could be higher level decisions as to *which* you want to install on multi-arch.
User pnasrat's account has been closed
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp