I oppose this.

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.

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

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.

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).

I guess openvrml itself can be made to depend on gecko-libs. It can also stop using an absolute version, I 
suspect.

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).

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.

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
firefox-*.pc.

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...

At a minimum, JS_CFLAGS, JS_LIBS, MOZILLA_PLUGIN_CFLAGS, and MOZILLA_PLUGIN_LIBS
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
generated.

The Right Thing here is probably to change this just to pull GRE_PATH out of
JS_LIBS.

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.

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.

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.

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'

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.

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.

--> Finished Dependency Resolution
Error: Missing Dependency: firefox = 2.0.0.9 is needed by package 
openvrml-xembed
# 

Looks like this is blocking f8 updates now.

Juha, that's unrelated.