On Friday, March 18, 2016 at 4:53:58 AM UTC-7, Sylvestre Ledru wrote:
> Le 17/03/2016 à 21:30, Henri Sivonen a écrit :
> > On Thu, Mar 17, 2016 at 2:28 PM, Sylvestre Ledru <sle...@mozilla.com> wrote:
> >> In Debian & Ubuntu,
> > I didn't find a rustc package on http://packages.ubuntu.com/ . What's
> > the situation on Ubuntu?
> I thought it was already synced for xenial. I just filled the request:
> https://bugs.launchpad.net/bugs/1559001
> >
> >> we use the official binaries provided to be able to build rust.
> > My same logic, can Mozilla-built rustc be used to build the Firefox
> > package as far as policy matters, with exceptions and waivers taken
> > into account, go? Or is this what's keeping rustc not getting past
> > testing?
> Debian stable will use the version of rustc at the time of the Debian freeze 
> (January 2017)
> >
> >
> > On Thu, Mar 17, 2016 at 2:47 PM, Sylvestre Ledru <sle...@mozilla.com> wrote:
> >> One way which would make the life of Linux distro way easier would be
> >> to maintain the Firefox rust code in a way it could compile using older 
> >> rust compiler.
> > In order to be competitive, we need all leverage we can get from our
> > Mozilla magic sauce (Rust). I think it's unacceptable to limit our
> > ability to leverage Rust in Gecko by forgoing the ability to co-evolve
> > Rust and Gecko at a rapid pace.
> I understand your point, it is just conflicting with the goals of Debian and 
> Ubuntu LTS.
> Mozilla wants to move fast, distros wants to provide stable products...
> >
> >> Now, with my Debian/Ubuntu hat, maintaining rust backports to be able to 
> >> build new versions of Firefox on stable/LTS releases
> >> is not going to be easy
> > Could Firefox in Debian stable have a build dependency on rustc from
> > Debian unstable?
> Nope, this doesn't work this way. Packages must be built in the env they are 
> going to be used.
> Otherwise, it would lead to side effects (different version of libraries used 
> for build time and runtimes).
> 
> 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.
> However, this is really the last option distros will consider (and I am sure 
> Glandium will choke when he will read this).

This seems like a workable solution, as horrible as it is. One could similarly 
make distro packages of rustc specifically for building firefox (called 
'rustc-fx' for example), and put them on the same ESR upgrade schedule as 
Firefox.

As another idea: Rust could maintain an LTS branch designed to be upgraded in 
conjunction with Firefox, that both keeps the language on a stable revision 
while also exposing backported features that Firefox needs in a controlled way. 
So Firefox would commit to being on e.g. 1.12 for 3 years, but could import 
'future' features. Then LTS distros would put rustc LTS point releases on the 
same upgrade schedule as Firefox ESR upgrades.

For Firefox this would require a lot of discipline. For Rust it would be a 
massive challenge coming up with a maintainable scheme. I'm actually thinking 
Rust could support multiple language revisions with a single compiler in a way 
that would allow old revisions to receive continual bugfixes and integrate 
'future' features; and that would be reliable enough that LTS distros could 
make major version bumps to rustc alongside Firefox while still deploying the 
language revision compatible with their LTS. Difficult and crazy.



_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to