Bug 517665 - "gecko-libs" provide should be arch-specific
Summary: "gecko-libs" provide should be arch-specific
Alias: None
Product: Fedora
Classification: Fedora
Component: xulrunner
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
: 519335 (view as bug list)
Depends On:
Blocks: 513526
TreeView+ depends on / blocked
Reported: 2009-08-15 20:05 UTC by Braden McDaniel
Modified: 2018-04-11 18:27 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-02-13 06:30:21 UTC

Attachments (Terms of Use)

Description Braden McDaniel 2009-08-15 20:05:50 UTC
Description of problem:
The "gecko-libs" provide needs to be arch-specific to keep things like this from happening:


Version-Release number of selected component (if applicable):

Comment 1 Matěj Cepl 2009-08-17 10:22:39 UTC
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.

Comment 2 Braden McDaniel 2009-08-17 13:37:45 UTC
That doesn't work if xulrunner does not provide arch-specific gecko-libs; this bug is about making that work.

Comment 3 Braden McDaniel 2009-08-26 11:24:48 UTC
*** Bug 519335 has been marked as a duplicate of this bug. ***

Comment 4 Christopher Aillon 2009-08-27 05:27:53 UTC
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.

Comment 5 Braden McDaniel 2009-08-27 20:53:51 UTC
(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?

Comment 6 Christopher Aillon 2009-08-27 21:43:10 UTC
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.

Comment 7 Braden McDaniel 2009-09-12 05:13:21 UTC
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.

Comment 8 Bug Zapper 2010-04-28 09:46:46 UTC
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: 

Comment 9 Christopher Aillon 2011-02-13 06:30:21 UTC
Anyway, I guess this is fixed now.  I still think this needs to be done in the rpm level, though.

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