Bug 352131 - openvrml should not depend on specific version of firefox
openvrml should not depend on specific version of firefox
Product: Fedora
Classification: Fedora
Component: openvrml (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Braden McDaniel
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-10-25 07:53 EDT by Lubomir Kundrak
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version: 0.16.7-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-16 16:09:19 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 Lubomir Kundrak 2007-10-25 07:53:13 EDT
Description of problem:

I believe the dependency of the package on specific version of firefox is
incorrect. The package should depend on gecko-lib instead.

Not having the correct dependency makes it harder to track packages that should
be rebuilt when firefox/gecko-libs is rebuilt and causes dependency and possibly
security problems.

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

Comment 1 Mamoru TASAKA 2007-10-25 09:08:05 EDT
I oppose this.
Comment 2 Braden McDaniel 2007-10-25 11:50:58 EDT
I don't see how changing the dependency to gecko-lib would solve anything. The
fact is, the dependency breaks whenever the location of libmozjs changes. And
because of the way firefox is deployed, that happens on any change to the
firefox version.
Comment 3 Lubomir Kundrak 2007-10-25 12:12:07 EDT
Braden: I'm not saying you won't have to rebuild the package on future firefox
updates. I just say is that your dependency is wrong, because you need
gecko-libs, not firefox. Just change Require: firefox = version to Require:
gecko-libs = version
Comment 4 Braden McDaniel 2007-10-25 12:32:36 EDT
But why is firefox wrong? Currently, it seems just to be another name for
gecko-libs. And if using gecko-libs isn't going to avoid any rebuilds, what's
being gained?

And what about the build dependency? firefox-devel has pkg-config metadata named
firefox-js.pc, which openvrml uses; I'm under the impression that a
gecko-libs-devel would provide that under a different name.
Comment 5 Christopher Aillon 2007-10-25 13:02:24 EDT
I asked lkundrak to file this.  Doing this will help the transition to xulrunner
as I start doing rebuilds against xulrunner versions.

It is also "more correct" since you are interested in gecko specifically, not
firefox itself (unless this is a firefox plugin).
Comment 6 Braden McDaniel 2007-10-25 13:57:51 EDT
I guess openvrml itself can be made to depend on gecko-libs. It can also stop using an absolute version, I 

But openvrml-xembed will still need to depend on firefox. The -rpath that gets used in the openvrml-
xembed executable has "firefox-<version>" in it because that's where libmozjs lives. Whether openvrml-
xembed actually needs the gecko parts strikes me as irrelevant as long as it is incompatible with any other 
provider without a rebuild.

And the build dependency will need to stay as firefox-devel (for the aforementioned reason).
Comment 7 Christopher Aillon 2007-10-26 06:56:20 EDT
There will never be more than one provider in Fedora, though.  I'd really
appreciate you changing all the dependencies that do not functionally require
firefox (such as a firefox-only extension) and can in theory depend on xulrunner
or seamonkey, etc. to gecko-libs or gecko-devel, even if there is a hardcoded
rpath for now.  I am likely going to change the path that firefox resides to
/usr/lib/gecko-%{version}/ in the near future as a part of the transition to
xulrunner which will help ease this.
Comment 8 Braden McDaniel 2007-10-26 12:41:30 EDT
There will, however, be providers that put the libraries somewhere other than
/usr/lib/firefox-<version> and name the pkg-config metadata something other than

The latter issue is really the crux of the problem; because the rpath is
determined based on the information openvrml's configure script extracts from
the pkg-config metadata. The configure script knows about mozilla-js.pc and
firefox-js.pc. It does not know about xulrunner-js.pc or gecko-js.pc or whatever
it winds up being called. So builds against providers that don't provide
pkg-config files that configure knows about will fail. Until that's fixed,
there's just not a way for openvrml to get built against an arbitrary
"gecko-libs" provider--and thus not a way for openvrml-xembed to get run with one.

So, looking at what it's going to take to fix this...

should be able to be overridden at configure time. The problem is a variable in
configure, GRE_PATH, which is computed based on output from pkg-config. Without
a usable pkg-config metadata file, it will fail and the proper rpath won't be

The Right Thing here is probably to change this just to pull GRE_PATH out of
Comment 9 Braden McDaniel 2007-11-06 20:38:51 EST
I have a patch to pull GRE_PATH from JS_LIBS, as previously described.

Now the missing piece is some bit of rpm magic that can emit "firefox-{version}"
or "xulrunner-{version}" (or "gecko-{version}"--whatever string gets used in the
path) based on the actual provider for gecko-devel. I don't know how to do that.
Comment 10 Lubomir Kundrak 2007-11-07 07:46:24 EST
Braden: Just add a BuildRequire to gecko-devel-<version> and bump <version> each
time new firefox (xulrunner in future) is released.

While tt would be probably possible to add an unversioned dependency and get the
version at build time using %(rpm -q --qf '%{VERSION}' gecko-devel) and make the
binary depend on in, I'd rather not recommend it as it is a bit messy.
Comment 11 Braden McDaniel 2007-11-07 11:25:28 EST
I need more than just the version. Without some way to get the directory name
for the Gecko libraries at build time, openvrml cannot be built against an
arbitrary gecko-devel provider.
Comment 12 Fedora Update System 2007-11-09 18:40:44 EST
openvrml-0.16.6-4.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update openvrml'
Comment 13 Christopher Aillon 2007-11-12 08:33:09 EST
Braden, you are trying to protect against a theoretical breakage.  That
theoretical breakage is if two different things provide identical gecko-devel
versions, and have different pathnames for the libraries.  While it is
theoretically possible in an uncontrolled environment, this will not be allowed
to happen in Fedora.

The approach you desire to take is a gross overcomplication of the simple
request to transition over to gecko-libs in the two or so weeks leading up to
XULRunner + Firefox 3 landing.  At that point, gecko-libs will be 1.9.x and will
not cause any conflict here.  There is no need to base things on JS_LIBS at all.
 I'd like to re-request you simply s/firefox-devel = 2.0.0/gecko-devel = 1.8.1/
and s/firefox = 2.0.0/gecko-libs = 1.8.1/ in the spec from prior to your changes.

Comment 14 Braden McDaniel 2007-11-13 02:54:32 EST
That's not what I'm trying to protect against. The issue is much simpler than
that: openvrml 0.16.6 can't be built against xulrunner without overriding
JS_{CFLAGS,LIBS} and MOZILLA_PLUGIN_{CFLAGS,LIBS} at configure time (rather than
rely on pkg-config).

That's not theoretical. For the reasons I've articulated in previous comments,
it just won't work. So, barring some mechanism for getting the right values for
the aforementioned variables at build time, you are suggesting that openvrml's
spec file advertise that it can be built against something that it cannot in
fact be built against.

Now, the good news is that the recently released openvrml 0.16.7 will look for
xulrunner-js.pc and xulrunner-plugin.pc. That should accommodate building
against xulrunner; and thus accommodate the changes you want.
Comment 15 Juha Tuomala 2007-11-13 09:34:04 EST
--> Finished Dependency Resolution
Error: Missing Dependency: firefox = is needed by package 

Looks like this is blocking f8 updates now.
Comment 16 Christopher Aillon 2007-11-13 09:44:54 EST
Juha, that's unrelated.

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