Bug 235758 - "has a -devel subpackage" heuristic for shipping multilib package needs improvement
Summary: "has a -devel subpackage" heuristic for shipping multilib package needs impro...
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact:
Whiteboard: bzcl34nup
Depends On:
Blocks: 189991 multilib
TreeView+ depends on / blocked
Reported: 2007-04-09 23:03 UTC by David Woodhouse
Modified: 2013-01-10 04:15 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-05-07 01:27:32 UTC
Type: ---

Attachments (Terms of Use)

Description David Woodhouse 2007-04-09 23:03:14 UTC
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.

Comment 1 David Woodhouse 2007-04-09 23:05:00 UTC
Hm, this should probably be filed against rpm first.

Comment 2 David Woodhouse 2007-04-09 23:25:47 UTC
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.

Comment 3 David Woodhouse 2007-04-09 23:58:11 UTC
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:

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?

Comment 4 Jesse Keating 2007-04-10 21:25:05 UTC
I'm not much help as the assignee.  Interested to see where this goes though.

Comment 5 Jeff Johnson 2007-04-25 00:24:09 UTC
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.

Comment 6 Jeff Johnson 2007-04-29 01:24:57 UTC
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.

Comment 7 Bill Nottingham 2007-08-10 14:06:24 UTC
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.

Comment 8 Red Hat Bugzilla 2007-08-21 05:33:39 UTC
User pnasrat@redhat.com's account has been closed

Comment 9 Panu Matilainen 2007-08-22 06:30:46 UTC
Reassigning to owner after bugzilla made a mess, sorry about the noise...

Comment 10 Bug Zapper 2008-04-04 00:01:10 UTC
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:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 11 Bug Zapper 2008-05-07 01:27:30 UTC
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:

Note You need to log in before you can comment on or make changes to this bug.