On Fri, Mar 18, 2016 at 05:23:21PM +0200, Henri Sivonen wrote: > You say you don't see #5 happening. Do you see #4 happening? If not, > what do you see happening?
At this point, I'm wondering if the best outcome wouldn't be 6) Distros die. I'm almost not joking. > > LTS distros do update Firefox because there is no way they can support > > security updates on older releases (I've done it with 3.5 long enough to > > know it's not tractable). But they do it once a year (at every ESR bump), > > not every 6 weeks. > > This is not the case for Ubuntu LTS. Even Ubuntu 12.04 gets a new > Firefox release every six weeks, and there is a package gcc-mozilla > that backports a GCC newer than the original GCC in 12.04 as a build > dependency: > http://archive.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_45.0+build2-0ubuntu0.12.04.1.dsc > > So, clearly, at least in the case of Ubuntu, there is precedent for 1) > updating Firefox every six weeks in LTS and 2) the Firefox package > having a build dependency on a compiler that's newer than the > compilers that originally shipped with the LTS system release. > > When I started this thread, I thought the s/IceWeasel/Firefox/ change > in Debian involved Debian starting to ship Firefox the way Ubuntu > does. For clarity: Is that not the case and Debian will only ship ESR > but an ESR that's within Mozilla's support period? I can see how > shipping ESR is the closest approximation of compliance with a policy > to ship outdated software, but how does ESR address Debian's package > dependency issues? If the next ESR requires a compiler that's not in > the current Debian stable, what then? > > Looking at > https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security > , it seems that Debian users get a more up-to-date Blink than Gecko. > If that policy is any indication, if ESR didn't exist, Gecko would get > the same deal as Blink... In other words, it looks like Debian > penalizes Gecko relative to Blink because ESR exists. :-( Well, at some point Blink wasn't even in stable. I'm actually surprised that it is now. But as a matter of fact, Debian's old stable is not receiving Blink/Chromium updates (it's stuck on 37), while it receives updates for Iceweasel (it has 38.7 as or writing, will receive 38.8, and 45.2 after that) > On Fri, Mar 18, 2016 at 1:01 PM, Sylvestre Ledru <sle...@mozilla.com> wrote: > > Debian stable will use the version of rustc at the time of the Debian > > freeze (January 2017) > > If Debian won't update rustc in Debian stable every six weeks, there's > going to be the downside that I quoted from Brian Smith above. Same > thing with Xenial if Ubuntu won't update the package every six weeks > throughout the LTS cycle. :-( > > I guess the upside is that then, in theory, the Debian Firefox source > package could include the source code of every Rust "stable" channel > rustc since Debian's freeze. > > > One dirty solution would be to ship rustc+llvm sources into Firefox sources > > when targeting stable distros. > > But this increases the load on the maintainers by an order of magnitude > > (maintainers will have to manage rust & llvm) > > and might not work if llvm starts requiring a more recent of gcc to build. > > Surely llvm can be built with clang, so you could include not only the > source of every rustc release since Debian's freeze but the source > code of every llvm and clang release since Debian's freeze... Except > then you'd need a policy exception for the anti-bundling policy. If > you need *some* policy exception no matter what, surely going for the > most sensible exception (letting both the Firefox package and the > rustc package update every six weeks within the LTS cycle) would make > the most sense. A 6GB source tarball, for a build taking 200 hours just for one architecture (I'm making up numbers, but I'm probably in the right ballpark). Times 10 supported architectures. You'd better not have a one-liner patch to apply on top of that. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
