User: Password:
|
|
Subscribe / Log in / New account

Beyond Firefox 4.0: Handling an accelerated development cycle

Beyond Firefox 4.0: Handling an accelerated development cycle

Posted Mar 10, 2011 8:14 UTC (Thu) by viiru (subscriber, #53129)
In reply to: Beyond Firefox 4.0: Handling an accelerated development cycle by AndreE
Parent article: Beyond Firefox 4.0: Handling an accelerated development cycle

> I've never understood why userland updates are so problematic. Adopting a
> system /world distinction like in FreeBSD would allow distros to maintain
> system stability while allowing users to run the most recent applications

It's not quite so simple. How does the distinction go with for example Firefox? It might seem to be an obvious case for "world" as it is a end user application. But is it? Let's take a quick look. On a Debian Squeeze system, there are 39 packages that depend on xulrunner (the rendering engine / user interface library of Firefox). You can't actually update Firefox without updating xulrunner, and if xulrunner is not fully backward compatible (it usually isn't), you may need to update the other 38 packages as well.

Some have claimed that Debian should ship an embedded copy of xulrunner with every depending package, but that just moves the problem to security updates (which are extremely frequent for our example case xulrunner), where instead of updating one package the security team needs to update all 39.

Does this help you see what the problem is?


(Log in to post comments)

Beyond Firefox 4.0: Handling an accelerated development cycle

Posted Mar 10, 2011 8:36 UTC (Thu) by epa (subscriber, #39769) [Link]

I don't understand why distros do not have a 'xulrunner-stable' which other apps depend on and which doesn't have to update whenever Firefox bumps its internal version of the XUL libraries. Since Mozilla (AFAIK) makes no commitment to provide a stable API for xulrunner, this seems a simple necessity.

But then, of course, somebody would need to backport security fixes to the stable xulrunner, so it's not that simple.

Beyond Firefox 4.0: Handling an accelerated development cycle

Posted Mar 10, 2011 8:45 UTC (Thu) by AndreE (guest, #60148) [Link]

As mentioned above, splitting the packages could work. Also, this problem is not so bad with libraries that don't break compatability. Those that do could follow a -stable / -new naming scheme if needed. I'm running firefox 4 from a repo on F14 that pulled in its own xul-runner, along side the system provided firefox 3 and thunderbird, so it does work (need to check the naming scheme)

Ultimately, I think a more granular update policy makes a lot of sense, and not just in this case. There is no reason that the firefox, xul-runner, or Open Office versions need to be as stable as the kernel version, Xorg version, or DE version throughout the lifetime of a distro.

Beyond Firefox 4.0: Handling an accelerated development cycle

Posted Mar 11, 2011 1:18 UTC (Fri) by nicooo (guest, #69134) [Link]

> Does this help you see what the problem is?

Yeah, xulrunner.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds