Re: Switching to mozilla ESR in stable-security
Hi,
On 05/28/2013 22:33, Moritz Muehlenhoff wrote:
> As such, we'll switch to releasing the ESR releases of iceweasel
> and icedove in stable-security.
> Reverse-deps of the older xulrunner libs have negligable security
> impact and we won't update them any further.
>
> One problematic aspect are the various xul-ext-* packages currently
> packaged. It's very likely that some of them will break with ESR17
> and ESR24 in the future.
>
> However, there's not much we can do here. We can select a narrow (!)
> set of important addons (e.g. enigmail for Icedove) that we will
> keep in sync through stable-security, but that doesn't scale for
> the full scale of Mozilla extensions currently packaged.
>
> In the future the majority of packages should thus rather be installed
> through http://addons.mozilla.org instead of Debian packages.
As mentioned on IRC, I wonder what we should do with these extentions
now and for future releases. There seem to be several options:
a) Remove most Mozilla extensions from stable/testing/unstable and
let users install them from addons.mozilla.org.
Important addons could stay if agreed with release and/or security
teams, e.g. enigmail (mentioned above) or adblock (part of the
default Debian GNOME installation).
b) Let maintainers update extensions via either -security or
-(proposed-)updates.
This causes additional work for the security team or the release
team for at least coordinating updates. I wouldn't expect them to
be able to review the changes which means a break from our current
stable policy.
b2) like b), but only do so for jessie and remove the extensions from
testing/unstable.
c) Let maintainers provide updated extensions via an additional
repository (e.g. mozilla.d.n or some developer repository).
I would expect some more packages giving us similar problems in the
future: other web browsers (chromium) or web applications (owncloud?)
where we might have to provide new upstream versions that require
updating related packages (or breaking them).
With my user hat on, I would like to have (b) though I'm not sure how
much work it would be.
I don't like (c). It's too similar to (b) with a workflow easy enough
for the release/security team.
Ansgar
Reply to: