Advertisement
Front, Kernel, Security, Distributions, Development. See your byline here on LWN.net.
| |||||||||||||
|
| |||||||||||||
firefox: policy bypassfirefox: policy bypassPosted Nov 20, 2008 18:35 UTC (Thu) by jspaleta (subscriber, #50639)In reply to: firefox: policy bypass by nix Parent article: firefox: policy bypass
Sarcasm?
Just FYI for those who don't get the joke. Fedora does use xulrunner. But xulrunner is not completely API stable. So if the API changes, and an application was making use of the unstable API, you can't just dump a new xulrunner into the updates pool.. you have to rebuild applications against the changed API.
The number of individual application rebuilds associated with an xulrunner package update in Fedora are a direct result of trying to be explicit about the fact that these applications are making use of parts of the gecko API which are considered upstream unstable. When those unstable APIs change, applications need to be rebuilt. The Fedora packaging policy concerning gecko-libs makes that explicit. If applications were only making use of the stable gecko API, then they wouldn't need to be rebuilt.
If Mozilla would stabilize the API, we wouldn't have to worry about it at all. But the reality is, its not completely stable, and applications which are built on top of the unstable API will need extra care.
I think this email below sums up the Fedora approach to the xulrunner API stability issue:
Want a comprehensive list of packages which use the unstable gecko API and will need rebuild consideration? Here it is for Fedora rawhide:
seahorse-plugins-0:2.24.1-2.fc10.src
Here's the list for stable API applications:
galeon-0:2.0.7-3.fc10.src
Applications which buildrequire gecko-devel but not gecko-devel-unstable should be okay without rebuilding when xulrunner updates. java for example.
-jef
(Log in to post comments)
firefox: policy bypass Posted Nov 20, 2008 23:01 UTC (Thu) by nix (subscriber, #2304) [Link]
No, no sarcasm: I assumed that xulrunner would reduce this horrendous
count somewhat, and that it was so huge because these apps weren't using xulrunner.
I had no idea so many apps were making use of the unstable API. That's
firefox: policy bypass Posted Nov 20, 2008 23:26 UTC (Thu) by jspaleta (subscriber, #50639) [Link]
This is only going to get better if we all make an effort to be explicit about where things stands. That way you know exactly which upstream project you should be talking to about reducing their dependence on unstable API bits. Maybe its the upstream apps could self-restrict to the stable API in some cases, maybe they can't.
The instability of gecko libraries has been a historic problem for distributors. The fact that external applications were built against it when its treated as an internal firefox API for so long is really unfortunate. But we are where we are, and it is what it is. We can't snap our fingers and force gecko-libs to be stable if the upstream work on the libraries isn't making API stability a priority. And we can't force application developers to only use the stable API.
A system wide xulrunner is better than having apps ship their on copies of the libraries, and trying to keep up with vulnerabilities across multiple copies and revisions of the same code scattered through many applications.
The question remains... who out there is trying to be explicit about the relationship between the stability of gecko-libs API and applications? Fedora is and we take our lumps for it by having people misinterpret the reason why so many apps get rebuilt when an xulrunner update goes out the door.
Which of the other distributors are making that effort to be as explicit and attempting to ensure that the unstable API doesn't cause an application runtime problem on xulrunner update? Which of the other distributors are even aware that there is a stable and unstable segment to the gecko libs API? I don't know. If you are using another linux distribution, it is your best interest to understand how your distributor handles this. Do you know how to tell which apps in the distribution you use use the unstable gecko API? Do they get rebuilt when xulrunner is updated? Ask the maintainers of firefox and xulrunner and apps which depend on libraries from either how they address the issue of gecko lib API instability as it relates to updates. The email url reference I gave previously is probably best reference I know that you can have your distribution's maintainer look at and comment on.
-jef
|
|
||||||||||||