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
