Bug 352131
Summary: | openvrml should not depend on specific version of firefox | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Lubomir Kundrak <lkundrak> |
Component: | openvrml | Assignee: | Braden McDaniel <braden> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | gecko-bugs-nobody, tuju |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | 0.16.7-1 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-11-16 21:09:19 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Lubomir Kundrak
2007-10-25 11:53:13 UTC
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. |