On Fri, Mar 18, 2016 at 1:10 AM, Nicolas B. Pierron <[email protected]> wrote: > This is not better from the point of view of distributions policy. > > This is better because you remove a lot of unknown variables from the > equation, and rely on a real package manager to package and distribute > software with its dependencies.
This seems off-topic to me. The matter at hand is dealing with distros' (particularly Debian's and Fedora's) policies in such a manner that there is no disruption to Firefox reaching users via these channels while Mozilla leverages Mozilla-developed tech in Firefox at the pace that makes sense for Mac, Windows and Mozilla's own Linux builds. Building a distro's Firefox binary package with a package manager that's not the distro's native one is very far off policy compliance. On Fri, Mar 18, 2016 at 1:59 AM, <[email protected]> wrote: > In particular, as > noted in this thread, you can't bootstrap off of either the current > version of Rust or the previous. This is actually a problem that could > be fixed in about one release cycle. Nice! I didn't realize it's that close to happening. I think it would be good to make "rustc stable N compiles with rustc stable N or rustc stable N-1" happen, then. It would probably make life easier not just for distro packaging but for non-x86/x86_64 ports as well, since those could self-host in a predictable way. > Even after hurdles of getting stable rustc into distros is solved I > think this is one of the most difficult issues. In particular, Firefox > needs to be buildable on the *stable* Rust compiler in order for > distros to build it. I've been assuming that Firefox would use the Rust "stable" channel compiler on the Firefox "release" channel, but I don't know if that has ever been really *decided* anywhere. Has it been decided? > Rust's nightly compiler contains unstable > features that we don't want used generally; it's the stable compiler > that we promote and want distros to package. If Firefox requires > nightly unstable features, then distros will be forced to package > nightly Rust. If those distros users learn to expect that the nightly > compiler is available then that could severely compromise Rust's > strategy for evolving the language. I think the best way to make sure that Firefox "release" channel builds with Rust "stable" channel rustc is to make sure that the theoretical notion of stability as the Rust project applies it and practical de facto stability do indeed go pretty closely together. An example of this *not* being the case: I expect to have to import https://github.com/gz/rust-cpuid into Gecko in order to cater to the Mozilla-side policy sadness of having to support Windows XP users whose computers don't have SSE2. That crate requires the asm! macro, which, according to https://internals.rust-lang.org/t/stabilization-path-for-asm/2610 , has been "barely updated" since Rust 0.6 and no one seems to have a concrete plan to redesign the feature, either. So the feature is de facto stable, but it's not theoreticall stable and continues to be unavailable in the "stable" channel. > If Rust produces 'universal' debs and rpms as suggested by @briansmith > that would be enough for distro *users* to build Firefox, but it's not > sufficient for the distro's themselves to keep their Firefox's up to > date. I think Rust should do this but it isn't clear that it solves a > critical problem. Indeed. I meant I agreed with this part of what Brian Smith said: "Debian Stable and Red Hat are notorious for maintaining old versions of packages way longer than anybody wants to support. With the great amount of improvement to rustc and Cargo, I think we're actually 1 or 2 years away from being able to expect any Rust library or application author to support any version of Rust older than the latest stable release. I personally don't want to be bothered by Linux distros asking me for free help in backporting changes or adding compatibility hacks to support old versions of rustc and Cargo that they ship. I imagine other people will feel similar." > Firefox's release model also has this tension with distros, and even > LTS distros *do* update Firefox, right? Ubuntu LTS updates Firefox at the Mozilla every-six-weeks schedule. >From Web sources, Fedora seems to, too, but I haven't actually verified this empirically. > Is there any chance Rust can > recieve updates like Firefox? >From my perspective, the best-case outcome of this thread would be exactly >that. On Fri, Mar 18, 2016 at 3:08 AM, Mike Hommey <[email protected]> wrote: >> We have less understanding of what it will take to get the major >> distros to a) actually deploy rust in a stable release, b) keep rust updated >> every 6 weeks. > > I don't see b) happening. Why not if 1) Firefox has to update every six weeks to get security updates and 2) rustc will become a build dependency for Firefox? That is, why wouldn't whatever policy exception allows the Firefox package pull a new upstream release every six weeks not allow rustc *as a build dependency for Firefox* to pull a new upstream release every six weeks? As far as I can tell, the problem is now overconstrained. Something has to yield. AFAICT, possible ways to make the problem not be overconstrained would be: 1) Mozilla is blocked from leveraging Mozilla-developed tech on Mozilla's schedule and has to slow down progress on all platforms (Mac and Windows included) in order to work at the slowest distro's schedule. 2) Some prominent distros stop shipping Gecko. 3) Some prominent distros ship an out-of-date Gecko without the current security patches from Mozilla. 4) Distros make a policy exception to allow Firefox to be have an out-of-archive build dependency. 5) Distros make a policy exception to allow not only the Firefox package but also it build-dependency rustc package to pull a new upstream release including non-security changes from upstream. A distro policy whose outcome is #1, #2 or #3 above hurts more than the policy helps. Therefore, it would be reasonable for distros to make a policy exception to go for outcome #4 or #5 instead. (I think outcome #1 is unacceptable and outcomes #2 and #3 would be very, very unfortunate. I think #5 would be the best outcome.) You say you don't see #5 happening. Do you see #4 happening? If not, what do you see happening? > 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. :-( On Fri, Mar 18, 2016 at 1:01 PM, Sylvestre Ledru <[email protected]> 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. > However, this is really the last option distros will consider (and I am sure > Glandium will choke when he will read this). I wish that an absurd outcome of policy would be taken as an indication to make a policy exception or to adjust the policy more generally to permit a rolling-ish subsection of the package archive where "stable" in the sense of "out of date" yields negative utility. -- Henri Sivonen [email protected] https://hsivonen.fi/ _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
