On Sun, Mar 20, 2016 at 9:53 PM, Petr Cerny <pce...@suse.cz> wrote: > I can't speak for Debian, but on SLE the solution we went for last time was > packaging new-enough GCC for older supported code streams, very much like > other packages (e.g. GTK) we had already needed way before.
This seems like a reasonable solution. As noted, it appears that Ubuntu backports GCC, too. >> The comments on https://bugzilla.mozilla.org/show_bug.cgi?id=1175546 >> suggest that Mozilla deferred relying on GCC bug fixes until after 45 >> ESR in order for Debian not to have to backport a compiler for >> oldstable. Is that the case? That is, is Debian's policy already >> hindering Mozilla's ability to avoid C++ compiler bugs that the >> compiler upstream has fixed? > > > TL;DR version: change whatever you need, but please do announce the intent > loudly, clearly and early enough. Great! > Longer version: > > It definitely is not just Debian. With all due respect, Mozilla doesn't rule > an isolated island - like all others it shares a jungle with other animals > of varying sizes, shapes and habits. Yes, but the Linux jungle depends on the outside for the browser engines (Gecko, Blink and WebKit) that it relies on and the numbers that Web developers look to assess the relevance of these engines (which translates into whether sites are made in a way that these engines work for Linux users) happens outside the Linux jungle. It's not reasonable for a part of the already small jungle to be entitled to limit the Gecko development inside and outside the jungle to old compilers. I want us to have good Linux support, I want obtaining our product to be convenient for Linux users and I don't want conflicts with the distros. I started this thread in order to avoid a situation where nobody saw it coming that we'd be about to land a patch that broke the distros' workflow by surprise. But consider: Rust as a technology works the best on Linux. (IIRC, debugging info works better on Linux than on Mac and it's pretty clear that Linux and Mac are better matches for Rust development than Windows.) It's very messed up that the tech that works the best on Linux is the hardest to ship to users on Linux. > I'm quite sure there are problems with > other compilers/systems than just GCC/Linux, but due to their larger target > user deployment and distribution model, they are being worked around. I know > it is different (in *many* aspects), but just imagine you had to solve a > similar issue with Microsoft or Apple (i.e. them distributing Firefox and > strongly preferring to build it with what they use for building the rest of > their systems with). I don't think a comparison with Microsoft and Apple is in the distros' favor. Microsoft's undocumented ABI has the practical effect of locking us to their C++ compiler, but they don't make us use just the C++ features and compiler bugs that were available when Windows XP shipped. Apple promotes clang and we are at liberty to use clang from llvm.org instead of Apple-shipped clang and we have the option to patch clang if we need to. As for imagining if Microsoft and Apple imposed requirements that they don't: The important point is that they don't! As for iOS, the requirement to use an Apple-designated language or compiler is gone. The policy problem with Apple is that they ban the class of product that we'd like to build on iOS. But AFAICT, using a rustc version of the developer's choice to build other kinds of products is already permitted on iOS. > Yet back to the point: you certainly can change whichever tool you need or > want, but the timing is crucial. Stable distribution maintainers are used to > these things happening every once in a while, so if you announce it loudly a > couple of releases ahead, it will be perfectly fine and nobody is going to > complain Not even Debian? > Generally, I think it shouldn't really be perceived as: "Linux distributions > are hindering our development", rather as being polite and respectful in a: > "Let's not make much more work for them unless it is really, really > necessary" manner. Which is exactly what shifting such a change from before > to after a major ESR release is. Considering how quickly Rust is progressing, chances are that the Firefox will pick up new rustc releases faster than on a 10-month cycle, so it will probably be safe to assume that every time there a new major release becomes ESR, it'll require a newer rustc than the previous ESR. But a mindset of "Linux distros can just ship ESR and deal with rustc at 10-month intervals" isn't a great solution when the distros have a non-enterprise audience or when the distros ship Chromium every six weeks; see below. > I think both sides want to achieve the same in the end: having a stable and > secure Firefox. It's not clear that that's the case when it comes to what "stable" actually means. If "stable" means "doesn't crash", sure. If "stable" means "out-of-date", the goals may not be aligned. There is a strong tendency towards "out-of-date" being seen as presumptively good in the enterprise space and Mozilla already accommodating that with ESR. However, when ESR spills over to a non-enterprise space (or to an enterprise that can entertain the idea of using Chrome/Chromium on a six-week update cycle), then having Firefox be "stable" as in "out-of-date" is not well aligned with moving the Web forward or being competitive with Chrome. That's why I think only shipping ESR would not be a good mechanism to deal with the upcoming rustc build dependency. On Mon, Mar 21, 2016 at 7:51 AM, Chris Peterson <cpeter...@mozilla.com> wrote: > How does Debian bootstrap other compilers like Go that are partially > self-hosted? Would a Rust compiler written in C/C++ (e.g. generated by an > LLVM back-end that emitted C/C++ code?) avoid the bootstrap policy > requirements? I think it's not fruitful to explore this angle. Evidently Debian is less strict about bootstrapping than Fedora (see what Sylvestre said in this thread; he is one of the Debian rustc packagers), and Fedora doesn't require bootstrapping from a compiler they already ship, either. As far as bootstrapping goes, the Fedora policy non-compliance issue is that currently rustc doesn't fulfill these (pretty reasonable, IMO) properties: > 2) Stable channel rustc being able to compile its corresponding > standard library. > 3) Stable channel rustc being able to compile itself. > 4) Stable channel rustc being able to be compiled with the previous > stable channel rustc. So as far as bootstrapping in distros goes, I think the focus should be on those properties and not on something more complex, and the comments from the members of the Rust core team in this thread suggest that things are on a good track when it comes to achieving those properties. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
