tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: pkgsrc/lang/rust



[moved to tech-pkg as this is important]

Havard Eidnes <he%NetBSD.org@localhost> writes:

>>>> Update rust to version 1.44.0.
>>>
>>> It's almost  freeze time.  I hope this builds on all pkgsrc platforms!
>> 
>> It certainly builds on NetBSD/amd64 8.0.
>> It also cross-builds for NetBSD/sparc64 8.0 on the above.
>> 
>> My build on NetBSD/i386 8.0 has been going for 8h, but won't be
>> finished before another 5 hours or so.
>
> Regrettably, the NetBSD/i386 8.0 build did not succeed, ref.
>
>   https://github.com/rust-lang/rust/issues/73117
>
> which I just submitted.  Is that sufficient reason to revert back
> down to 1.43.1?

Let me first say that I have not been hacking on rust, either the
compiler, code in it, or trying to make bulk builds work.  I have just
been doing builds locally and raising issues.

My basic perception is that every time there is a rust update, people
have trouble building it on multiple platforms, and evenentually that
gets straightened out.  But as you are closer to this than me, please
let me know how you see it.

Having working binary packages, reasonably promptly, is a big deal for
users.  And, I think it's important that people building things from
pkgsrc have a very high rate of success when just typing make package,
particularly in stable branches.  In current, I think some breakage is
ok, but really only if it can be fixed in a few days once reported.

So, heading to 2020Q2, my notions of what ought to be is:

  lang/rust will just build, the first time, everywhere*

  firefox will also just build, the first time, everywhere

  when the branch is cut, bulk builds will be kicked off, and they will
  all succeed the first time

  *everywhere means except where it is excluded by ONLY_FOR or
   BROKEN_ON, and we don't add to that without discussion ahead of time.
   Obviously none of this works on 7, or on vax.


This is harder because dependencies are serial; people can't even test
build firefox until rust builds.  firefox on 8/amd64 was broken in
2020Q1, and it's hard to say exactly why, but juggling two issues at
once is much harder than one.


The other question is whether rust needs to be at 1.44, vs 1.43, for
2020Q2.  We have a cutoff for updates, and pmc is discussing making that
earlier for packages that have a history of causing problems.  My
perception is that rust updates are fairly frequent, and firefox needs
something fairly recent, but not immediately.

So my inclination is that it is good to revert this (it was only
released 4 days ago) because it's far more important to be stable than
to be recent.  We have already seen that 1.44.0 doesn't build, we don't
know what the next problems are, and as I see it we have no good basis
from which to predict meeting the stability notion above within a few
days.


Home | Main Index | Thread Index | Old Index