Bug 378591 - Binary package not in tree
Binary package not in tree
Product: Fedora
Classification: Fedora
Component: yaboot (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-11-12 14:15 EST by Jonathan S. Shapiro
Modified: 2008-02-15 21:28 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-12 14:25:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jonathan S. Shapiro 2007-11-12 14:15:35 EST
The yaboot source rpm made it into the F8 tree, but the i386 binary package is
missing. Other binary packages may also be missing -- I have not checked.

This is moderately bad, as yaboot is a *required* package according to the F8
comps file...
Comment 1 David Cantrell 2007-11-12 14:25:59 EST
From yaboot.spec:

ExclusiveArch: ppc ppc64

And on the download site:


I'm guessing you are running through the package trees to see what is missing
from F-8.  That's good, but keep in mind a lot of packages are only for specific
architectures.  yaboot is the ppc boot loader, so you wouldn't have it on i386.
Comment 2 David Woodhouse 2007-11-12 14:37:35 EST
Scripting something to file such bugs is good -- any package with an ExcludeArch
or ExclusiveArch should have a bug filed for that, even if it's just a
placeholder like this one because there is a valid long-term reason for the

These bugs should be on the appropriate FE-ExcludeArch-$ARCH tracker bugs though.
Comment 3 Jonathan S. Shapiro 2007-11-12 15:17:07 EST
You guys know the release process better than I do. My bottom line is that my
attempt to use revisor to do a respin for i386 whined about a missing package.
If that's a revisor bug, well and good, but it seems to me that there is also a
bug in the "comps" mechanism if the package is arch dependent and not somewhere
marked as such.

Sorry, I don't know enough about anaconda to have a sensible opinion about which
package(s) need their opinions revised, but the end behavior of revisor was
clearly wrong. Can you suggest which package should get a bug filed?
Comment 4 David Cantrell 2007-11-12 15:25:35 EST
If you have your yum repos set up properly, yum will give you the list of valid
packages for your architecture.  yum figures this stuff out from the repodata
and the comps file.

In Python, you can do something like this:

import yum
y = yum.YumBase()
y._getConfig(debuglevel=0, errorlevel=0)

validpkgs = []
for sack in y.pkgSack.returnPackages():

The information you are wanting is not entirely encoded within the comps file,
so you will need to use yum to get at it.  The above is just an example, but my
guess is that revisor needs to be modified.  All of the tools we use for
installation and tree composition build on yum.
Comment 5 Paul Nasrat 2007-11-12 17:43:06 EST
yum api also supports an arch= to do overrid, so modifiying repoquery to allow
this might be possible. pkgorder already uses this mechanism (although you have
to do mapping to an archlist really to make it work for eg basearch i386
containing i586 and i686 rpms). Adding something like --basearch, also cf
repoclosure which supports --arch already
Comment 6 Jeroen van Meeuwen 2008-02-15 21:27:20 EST
Revisor does use yum all the way. When it comes down to selecting groups, like
@core and @base, Revisor gets the mandatory, default and optional packages from
these groups and tries to select them. If yaboot is in @core but not available
in the repositories (for example when composing non-ppc), Revisor will complain.
Same goes for all other packages that may or may not be "missing".

I consider this a short-coming of comps.xml, but I'm not sure if and how to fix it.

Not complaining about missing packages (by adding --ignore-packages to %packages
which Revisor also uses) causes the user not to be warned for other, more
explicitly included files as well.

Getting Revisor not to complain about @core packages missing might seem like a
viable solution, until someone decides to not use the upstream repo or other
small repositories and start off with just a couple of RPMs in a directory.

Keeping a list in Revisor with information on which packages are missing for
what architecture creates (too much?) administrative overhead, but seems to be
the best solution to me.

Ideas welcome ;-)

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