Hi! We are holding off on packaging with nix for a couple quarters because of how much work in the TC-worker we have ahead of us.
Let's have a nix conversation the first week of the quarter and then we can see what low hanging fruit there is. Right now, lots of people are stressed with gsoc and outreachy and end of quarter goal work :) I'm so glad you're advocating for this :). Have you talked with gps at all about nix and reproducible builds? -Selena On Thu, Mar 24, 2016 at 4:50 AM Petr Cerny <pce...@suse.cz> wrote: > Henri Sivonen wrote: > > On Wed, Mar 23, 2016 at 1:51 AM, Petr Cerny <pce...@suse.cz> wrote: > >> Saying "Linux is good, we can actually do things there, that are > >> more complicated elsewhere, but you are hindering our development" > >> sound a bit unfair. > > > > There is no contradiction between Rust working the best on Linux and > > being of the opinion that limiting ourselves to Rust features that > > were part of rustc when Debian stable last shipped is not okay. > > Clearly, there are distros that are don't have a policy issue with > > Firefox gaining a dependency on an actively-developed compiler. It's > > just that the need of a policy exception is what generates email. > > Right, but Debian is part of the ecosystem. I think you might have > (unpleasant) reminiscences about the later days of WinXP, but people > were using it for some reason, and I bet they have good reasons to use > Debian stable and not some faster moving distributions. > > > It's hard for me to tell if you represent a distro with which a > > rustc dependency will be a non-issue, since your comments run the > > gamut of implying your distro had a compiler bootstrapping policy > > stricter than Fedora's to saying that six weeks is viable. > > Because it all depends on precise conditions. (And my comments were > meant also more generally than just for SLE). Six weeks is viable > technically iff all works as expected. Like Sylvester mentioned, once > there is a hiccup (rustc pulling in an update of llvm, llvm pulling in > update of gcc) we're all out of luck. > > The dependency on non-stable build tools is not just a technical problem > - anyone not having a special taste for using bleeding edge technologies > will tell you such approach is broken. It may help the development big > time, but for packagers it is just pain. > > >> The all-from-source, stable interfaces and similar policies are > >> there for a reason. > > > > Again, "stable" is a loaded word. Maintaining interface > > compatibility in the sense that stuff written to the old interface > > doesn't break on update is reasonable to want, but e.g. in the case > > of Debian that's not the criterion for getting to update a package > > (absent policy exception). rustc maintains compatibility in the sense > > that source code that compiled with some version (1.0 or later) of > > rustc continues to compile with later versions. > > Which is good, but only half of the problem. The other is that the > language itself is not stable enough to provide some sort compatibility > in the other direction. Which is why (with my limited understanding of > Debian policies) assume it could live in Unstable or Testing but not > Stable. > > > As I understand Debian policy, even if upstream says that it's their > > explicit goal to maintain compatibility in the sense that new > > versions don't break stuff written for old versions, Debian assumes > > that upstream won't meet such a goal and instead only cherry-picking > > security fixes from the upstream is permitted (absent the sort of > > exception Chromium got). > > Well... most of the time things work. The problem are the cases when > seemingly innocent upstream changes break working setups (because > upstream doesn't care about history, they want progress). Policies like > this are motivated exactly by this sort of things happening in the past. > Does Chromium pull in new versions of compilers or comparable packages > every other month? > > >> Actually you could package Firefox for generic Linux by building > >> your own GCC and bundling all libraries (the whole GTK stack) into > >> the tarball/rpm - at some point replicating good portion of > >> packages installed on an average desktop system. ... You don't > >> want to go there. > > > > Mozilla already ships binary tarballs compiled with a GCC version of > > Mozilla's choice. Those tarballs don't even need to include GTK+, > > because except for the changes between gtk2 and gtk3, GTK+ does a > > good job maintaining ABI compatibility. > > Let's just say that we do have separate GTK package for Firefox on older > SLE code streams. Although "older" in this case is not the 3-5 years you > would see with Debian. I think you understand my feelings the day it > turns out I'll have to package and regularly update LLVM and rustc every > 6 weeks... > > >> Distributions should be fine with 6 weeks, if changes are announced > >> with reasonable time buffer. > > > > I'd expect it to make sense to update rustc every six weeks without > > specific notice. Maybe Firefox won't need a new rustc for every > > Firefox release, but considering the pace of development of rustc > > and the Rust standard library, I think it would make the most sense > > to plan with the assumption that both Firefox and rustc update every > > six weeks. > > OK, but 6 weeks for a compiler update is not big-enough time buffer: if > at some point rustc indeed pulls in newer LLVM things will get nasty. > You can't update system LLVM, so you have to build a separate one. If > that one for some reason requires newer GCC... well you get the picture. > > If you can guarantee such things won't happen, good. Telling packagers 6 > weeks ahead that for Firefox update they will need newer LLVM and > possibly newer GCC is not a thing that will happen twice. > > >> So 6 weeks clearly is viable now. > > > > Great! > > With the above reservations. To make sure I'm clear (I might have not > explicitly given it that much prominence throughout the discussion): > > 6 weeks update cycle is workable, iff the changes with bigger impact are > announced much earlier. Example: > > Good: "We have 6 weeks release cycle. You will need to update LLVM in 5 > release cycles from today, because we are going to introduce features > that we are not able to implement with the one we are currently using." > > Bad: "We have 6 weeks release cycle. You will need to update LLVM in in > 7 weeks, because in the next release we are introducing features that we > are not able to implement with the one we are currently using." > > I'd see it as a tax for using rapidly evolving tools on something that > part of users wants to perceive as stable (and personally I don't think > changing this very perception is a good idea). > > > But if you also ship rapid-release Firefox in addition to ESR, > > surely you'll need the rustc versions between X and X+7 for that. > > Since rustc continues to compile old programs, you could build > > Firefox Y.0.Z ESR with rustc X+Z, so you shouldn't need to keep an > > older rustc around for Firefox ESR while you are updating rustc to > > compile non-ESR Firefox. > > For example SLE doesn't ship RR Firefox. As for the RR to ESR backports, > AFAIU Rust was intended to minimize number of security bugs, so good > portion of what is backported shouldn't touch Rustified codebase. So it > should be a bit easier to keep rustc needed for ESR stable throughout > its lifetime. > > >> Stable for LTS/enterprise means: doesn't change existing interfaces > >> and functionality. As in: f(x) is always be available, does f(x) > >> and only f(x). > > > > The main issue is whether you're allowed to add g(y) that does g(y) > > during the LTS cycle. > > > >> As far as I understand, rustc is not in this area yet when a > >> timeframe of the order of months/years is considered. > > > > Starting with Rust 1.0, you should expect new rustc releases not to > > break f(x) even if they add g(y). > > That's a Yes for me. But remember, "f(x) ===== f(x)" is a must (as the > number of equal signs suggests), even counted with possible side > effects. That I think can be considered a stable technology. > > >> The tendency to equate stability with out-of-date you mention > >> usually comes from people who haven't experienced servicing > >> long-running systems. > > > > AFAICT, equating "stable" with "out-of-date" (plus security-only > > cherry-picks) is factually correct when it comes to e.g. Debian > > (except the Chromium package). I'm not familiar with your distro's > > notion of stability. > > Pretty much the same. From time to time we do upgrade packages, because > such a request comes from the outside (customer). > > > Again, I don't yet understand if your distro's policy is at odds > > with making Firefox depend on rustc. However, it seems to me that > > Debian's is and what Sylvestre (suggested Firefox maintaining > > compilablility with the rustc that was current when Debian stable > > shipped) and Mike (not seeing rustc updating every six weeks > > happening) have said in this thread seem to support that notion. > > Actually we are very similar here as well - I don't think we'd be > releasing rustc for general use, until it reaches at least some level of > stability/maturity (feature-wise as well). My guess is it will be used > for Firefox builds only, and that is why it should work. Generally it is > what Sylvestre suggested: having rustc in the Firefox (er, Iceweasel) > package. > > >> I'm not sure you are fully aware of the main reason behind ESR. It > >> is mostly testing internal enterprise web applications and > >> add-ons, which often takes over a month. For exactly this reason > >> there is a 3 months overlap (or even 4.5 if one counted -beta) and > >> some 9 months of support. > > > > I'm well aware that the ESR schedule is based on that idea of > > intranet compatibility testing. It's not clear to me if what > > proportion of ESR recipients actually perform the testing as > > intended. > > I know that at least some do (especially when their internal workings > depend on it). > > >> This actually also suggests that it is better to leave more > >> fundamental changes in functionality the releases shortly after ESR > >> release > > > > It seems like a good time to talk about Rust now that there is no > > risk of anyone thinking that Rust code would be going into 45 ESR. > > Agreed, the part about trying to keep rustc stable during ESR was more > important in this very discussion. I just wanted to point out the > complementarity. > > Thanks > Kind regards > Petr > -- > Petr Cerny > Mozilla/OpenSSH maintainer for SUSE Linux > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
