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...
From yaboot.spec: ExclusiveArch: ppc ppc64 And on the download site: http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Fedora/ppc/os/Packages/yaboot-1.3.13-5.fc8.ppc.rpm 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.
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 exclusion. These bugs should be on the appropriate FE-ExcludeArch-$ARCH tracker bugs though.
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?
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(): validpkgs.append(sack.name) 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.
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
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 ;-)