In last week's QA meeting, Chris Aillon (aka caillon, our fearless firefox/xulrunner maintainer) stopped by to tell us what happened with xulrunner dep breakage, and how package maintainers can help reduce / prevent it in the future. Here's a quick summary:
There are two APIs provided by xulrunner - the stable API (gecko-devel), and the unstable one (gecko-devel-unstable).
The stable API, as you might guess, is not expected to change. So if a package uses the stable API, it won't have any problems when the xulrunner package is updated. The unstable API could change at any time, so if your app is using the unstable API it must be rebuilt *every time* xulrunner is updated.
Packages using the stable API should have: Requires: gecko-libs >= 1.9 BuildRequires: gecko-devel >= 1.9
Packages using the unstable API should have: %define gecko_ver 1.9.0.1 Requires: gecko-libs = %{gecko_ver} BuildRequires: gecko-devel-unstable = %{gecko_ver}
Anything with BuildRequire: xulrunner-devel or xulrunner-devel-unstable should be changed to gecko-devel or gecko-devel-unstable. (The xulrunner-devel packages provide those things).
Also: if your package uses the -unstable API, please send caillon@redhat.com a note, and *please* consider adding him to the ACL (or opening it entirely). He keeps tabs on all packages requiring the unstable API so they can all be rebuilt for each security update.
caillon is out 'til next week, so it would be really good if you can help clean this stuff up in his absence.
Thanks!
-w
On Tue, 2008-07-29 at 11:54 -0400, Will Woods wrote:
In last week's QA meeting, Chris Aillon (aka caillon, our fearless firefox/xulrunner maintainer) stopped by to tell us what happened with xulrunner dep breakage, and how package maintainers can help reduce / prevent it in the future. Here's a quick summary:
There are two APIs provided by xulrunner - the stable API (gecko-devel), and the unstable one (gecko-devel-unstable).
Why does xulrunner-devel-unstable provide some of the same headers (at a different path) that xulrunner-devel does? I'm specifically noticing SpiderMonkey headers; though there might be others.
Braden McDaniel wrote:
Why does xulrunner-devel-unstable provide some of the same headers (at a different path) that xulrunner-devel does? I'm specifically noticing SpiderMonkey headers; though there might be others.
Good question, I asked about the same thing in my mail a while ago: https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01150.html.
My package mozvoikko needs e.g. mozISpellCheckingEngine.h, which is in /usr/include/xulrunner-sdk-1.9/spellchecker/ (xulrunner-devel) and in /usr/include/xulrunner-sdk-1.9/unstable/ (xulrunner-devel-unstable). Using directories like "spellchecker" I can get mozvoikko to build without the unstable devel package, but I wonder if I need the "unstable requirements style" or will the "stable requirements style" do.
Braden McDaniel wrote:
On Tue, 2008-07-29 at 11:54 -0400, Will Woods wrote:
In last week's QA meeting, Chris Aillon (aka caillon, our fearless firefox/xulrunner maintainer) stopped by to tell us what happened with xulrunner dep breakage, and how package maintainers can help reduce / prevent it in the future. Here's a quick summary:
There are two APIs provided by xulrunner - the stable API (gecko-devel), and the unstable one (gecko-devel-unstable).
Why does xulrunner-devel-unstable provide some of the same headers (at a different path) that xulrunner-devel does? I'm specifically noticing SpiderMonkey headers; though there might be others.
It's been almost two weeks and this question hasn't been answered yet, any comments anyone?
Ville-Pekka Vainio wrote:
Braden McDaniel wrote:
On Tue, 2008-07-29 at 11:54 -0400, Will Woods wrote:
In last week's QA meeting, Chris Aillon (aka caillon, our fearless firefox/xulrunner maintainer) stopped by to tell us what happened with xulrunner dep breakage, and how package maintainers can help reduce / prevent it in the future. Here's a quick summary:
There are two APIs provided by xulrunner - the stable API (gecko-devel), and the unstable one (gecko-devel-unstable).
Why does xulrunner-devel-unstable provide some of the same headers (at a different path) that xulrunner-devel does? I'm specifically noticing SpiderMonkey headers; though there might be others.
It's been almost two weeks and this question hasn't been answered yet, any comments anyone?
Hadn't noticed it sorry. Unstable builds need to be able to use the stable headers, too. The duplication is unfortunate, but it's a byproduct of the way the pkgconfig files are done. They include either a stable or unstable subdirectory, and sorting out the symlinks would be a pain.
On Mon, 2008-08-11 at 15:33 -0400, Christopher Aillon wrote:
Ville-Pekka Vainio wrote:
Braden McDaniel wrote:
On Tue, 2008-07-29 at 11:54 -0400, Will Woods wrote:
In last week's QA meeting, Chris Aillon (aka caillon, our fearless firefox/xulrunner maintainer) stopped by to tell us what happened with xulrunner dep breakage, and how package maintainers can help reduce / prevent it in the future. Here's a quick summary:
There are two APIs provided by xulrunner - the stable API (gecko-devel), and the unstable one (gecko-devel-unstable).
Why does xulrunner-devel-unstable provide some of the same headers (at a different path) that xulrunner-devel does? I'm specifically noticing SpiderMonkey headers; though there might be others.
It's been almost two weeks and this question hasn't been answered yet, any comments anyone?
Hadn't noticed it sorry. Unstable builds need to be able to use the stable headers, too. The duplication is unfortunate, but it's a byproduct of the way the pkgconfig files are done. They include either a stable or unstable subdirectory, and sorting out the symlinks would be a pain.
Having the unstable headers depend on the stable ones seems like the right approach here.
Modifying the pkg-config metadata to include -I flags for both the stable and unstable directories is easy enough; so a state other than that strikes me as another symptom of the problem rather than the point of failure itself.
Is the problem you allude to ("sorting out the symlinks") that upstream is dumping these stable headers (or symlinks thereto) in the unstable hierarchy? If so, that seems worthy of an upstream bug report.
On Tuesday 29 July 2008 08:54:51 Will Woods wrote:
Packages using the stable API should have: Requires: gecko-libs >= 1.9 BuildRequires: gecko-devel >= 1.9
How would we go about requiring only 1.9* versions? I would like the spec/package to break if/when xulrunner goes to the next version (obviously not in this release, but at some point in the future).
For example, I can't do: Requires: gecko-libs < 2.0
Because I'm not guaranteed that the next version will *be* 2.0 (it might be 1.10, for example).
Perhaps it would be best if xulrunner also added something like:
Provides: gecko-libs-api = 1.9
-Doug
Packages using the stable API should have: Requires: gecko-libs >= 1.9 BuildRequires: gecko-devel >= 1.9
How would we go about requiring only 1.9* versions? I would like the spec/package to break if/when xulrunner goes to the next version (obviously not in this release, but at some point in the future).
For example, I can't do: Requires: gecko-libs < 2.0
Because I'm not guaranteed that the next version will *be* 2.0 (it might be 1.10, for example).
It won't be 2. Firefox 3.1.x will ship with gecko 1.9.1.x where as FF 3.0 uses gecko 1.9.0.x. No idea how you'd specify that in rpm though.
Peter
On Tue, Jul 29, 2008 at 8:45 PM, Peter Robinson pbrobinson@gmail.com wrote:
Packages using the stable API should have: Requires: gecko-libs >= 1.9 BuildRequires: gecko-devel >= 1.9
How would we go about requiring only 1.9* versions? I would like the spec/package to break if/when xulrunner goes to the next version (obviously not in this release, but at some point in the future).
For example, I can't do: Requires: gecko-libs < 2.0
Because I'm not guaranteed that the next version will *be* 2.0 (it might be 1.10, for example).
It won't be 2. Firefox 3.1.x will ship with gecko 1.9.1.x where as FF 3.0 uses gecko 1.9.0.x. No idea how you'd specify that in rpm though.
< 1.9.1 ?
On Tuesday 29 July 2008 11:48:53 drago01 wrote:
It won't be 2. Firefox 3.1.x will ship with gecko 1.9.1.x where as FF 3.0 uses gecko 1.9.0.x. No idea how you'd specify that in rpm though.
< 1.9.1 ?
Like I suggested; perhaps:
Provides: gecko-libs-api = 1.9
So packages could require this specific version without allowing allowing future versions that would possibly break.
-Doug
Douglas E. Warner wrote:
On Tuesday 29 July 2008 11:48:53 drago01 wrote:
It won't be 2. Firefox 3.1.x will ship with gecko 1.9.1.x where as FF 3.0 uses gecko 1.9.0.x. No idea how you'd specify that in rpm though.
< 1.9.1 ?
Like I suggested; perhaps:
Provides: gecko-libs-api = 1.9
Could xulrunner please use libtool-style soname versions like all other libraries in Fedora ? So we don't need to add the version numbers in the spec file in the first place... Frankly, this would never pass a standard fedora package review.
Will Woods wrote:
In last week's QA meeting, Chris Aillon (aka caillon, our fearless firefox/xulrunner maintainer) stopped by to tell us what happened with xulrunner dep breakage, and how package maintainers can help reduce / prevent it in the future. Here's a quick summary:
There are two APIs provided by xulrunner - the stable API (gecko-devel), and the unstable one (gecko-devel-unstable).
The stable API, as you might guess, is not expected to change. So if a package uses the stable API, it won't have any problems when the xulrunner package is updated. The unstable API could change at any time, so if your app is using the unstable API it must be rebuilt *every time* xulrunner is updated.
Packages using the stable API should have: Requires: gecko-libs >= 1.9 BuildRequires: gecko-devel >= 1.9
Packages using the unstable API should have: %define gecko_ver 1.9.0.1 Requires: gecko-libs = %{gecko_ver} BuildRequires: gecko-devel-unstable = %{gecko_ver}
Maybe consider something like this to help both stable/unstable camps: Provides: gecko-libs(1.9) = 1.9.0.1
Then "stable" folks could Requires: gecko-libs(1.9)
and "unstable" folks Requires: gecko-libs(1.9) = 1.9.0.1
-- Rex