Bug 517665

There is an alternative way in the thread suggested by seth. Anybody who wants arch-specific bits of xulrunner should require:

Requires: gecko-libs%{_isa} = <version>

Not sure, which of these two solutions make more sense. Leaving it to developers to decide.

That doesn't work if xulrunner does not provide arch-specific gecko-libs; this bug is about making that work.

*** Bug 519335 has been marked as a duplicate of this bug. ***

So, to me, this sounds like rpmbuild is broken and should be made to generate the correct provides.  Named provides always want to be both:

  foo = ver-rel
  foo%{_isa} = ver-rel

I believe that rpmbuild should auto generate both when an explicit Provides is given for an arch-specific package, and possibly even for noarch packages, if the norm is foo(noarch) = ver-rel.

It's silly to litter this stuff around in tons of spec files.

(In reply to comment #4)
> Named provides always want to be both:

Why is this true? Sure, in the cases of gecko-libs and java, they may be dependencies for architecture-independent things. But that's a function of the nature of these particular examples; why would a named provide "always" want to have an arch-independent variant?

The better question is why wouldn't they?  If you are providing something from an arch dependent package, you are providing something for that specific arch.  To not provide that is wrong, and can lead to bugs such as this.  The only reason we do not see this more frequently is because of the .so provides and requires which rpm generates with arch information.  If rpm did not generate those, we'd see this a lot more often since a package would then be aware it needs to e.g. Requires: gtk2%{_isa}

But even then, gtk2 would still not be expected to Provides: %{name}%{_isa}.  In fact, that currently gets generated automagically, too by rpmbuild.  However for a noarch package, it appears that does not get generated.  IMHO, that is correct.  If the package is noarch, it does not matter what arch it is.  If it is arch-specific, then clearly the arch means something everywhere in that package.

I feel strongly that this should be taken up with the rpm folks.  I would be okay with it being %define'able (similarly to e.g. %_default_patch_fuzz) but I do not believe that spec files should have to manually say

Provides: foo
Provides: foo%{_isa}

That's just madness and error prone.

Okay, I agree.

Meanwhile, your broken package is preventing packages that depend on it from being able to apply the correct Requires and a patch of a few lines would fix that.

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Anyway, I guess this is fixed now.  I still think this needs to be done in the rpm level, though.