tech-pkg archive

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

Re: Rust and Q-branching



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

>>> As we approach the next stable Q-branching, I wonder if we plan to
>>> ship it with Rust-1.52.1 ?
>> 
>> https://www.pkgsrc.org/quarterly/
>>
>> Absent an update staged in wip, an argument that nothing will break,
>> discussion and PMC approval (which is merely observing that the argument
>> was made and that the larger group buys the argument), it is too late to
>> update rust, now that it is after September 1.
>
> That's unfortunate.

As I see it what is unfortunate is the underlying situation with rust,
particularly the culture of needing very recent versions for
bootstrapping and building depending packages, and the history of
difficulty with updates that has led us to be careful.  And also the
nature of pkgsrc is that cascading issues of toolchains and then other
things that more or less have to be fixed in series can lead to churn in
freeze and coming out with things broken.  Overall the sense I have
gotten is that not having working firefox binary packages in quarterly
branches is a huge issue, at least for common os/version/arch tuples.

We have decided not to have N versions of rust in pkgsrc, which would
allow flipping platforms separately, but have a lot more complexity.  I
am not super inclined to revisit that, as things are mostly ok other
than when updates land just before freeze, rather than coming earlier.
But it's of course a fair subject for discussion.

I realize you are doing most of the rust work, and it would be great if
others helped, and were able to have a concerted push to bring rust up
to date around 2/1 - 2/15 within a quarter.  Then we have time to
recover to be stable again before starting to think about branching.

But all that is generalities and the real question right now is if we
can convince ourselves if the new version isat least as ok as the
version we have now.

Are you saying that what is right now in wip/rust is, more or less
exactly, something you believe is likely safe to update lang/rust?  In
other words, is testing wip/rust valid in terms of checking the proposed
update?

If so, it would be good for people to test it and report here how it
goes.

>> I do see rust 1.54.0 in wip.  But any update needs to not cause failures
>> to the build of rust and also things that depend on rust, on pretty much
>> all platforms where they work now, so that we don't enter the freeze
>> with e.g. firefox not building.  I have no idea what platforms that
>> builds on so far.
>
> I have at least an existence proof that rust 1.54.0 permits the
> build of firefox 91.0.2 on NetBSD/amd64 9.99.81, and the result
> appears to work just fine, or at least as well as firefox did
> before.
>
> I have builds ongoing for i386 (8.0 and 9.2), but it's taking a
> while.  Rust itself builds, at least.
>
> What other platforms do we need this tested on?  arm64, perhaps?

I am not 100% sure, but I think testing is required at least on:

  NetBSD {8, 9, current} x {i386 amd64 earmv7hf-el aarch64 sparc64}
  illumos (amd64 only I think)

and it might be that sparc64 doesn't work in the current state, or not
on 8, and I am unclear about aarch64-mac.  I am also unclear if people
care about pkgsrc rust on Linux, but I suspect they do.

Looking at the current package I see boostraps:

Size (rust-1.51.0-aarch64-apple-darwin.tar.gz) = 265367526 bytes
Size (rust-1.51.0-aarch64-unknown-linux-gnu.tar.gz) = 352805576 bytes
Size (rust-1.51.0-aarch64-unknown-netbsd.tar.gz) = 235129929 bytes
Size (rust-1.51.0-arm-unknown-linux-gnueabihf.tar.gz) = 301971516 bytes
Size (rust-1.51.0-armv7-unknown-linux-gnueabihf.tar.gz) = 292904493 bytes
Size (rust-1.51.0-armv7-unknown-netbsd-eabihf.tar.gz) = 211192792 bytes
Size (rust-1.51.0-i586-unknown-netbsd.tar.gz) = 254835447 bytes
Size (rust-1.51.0-i686-unknown-linux-gnu.tar.gz) = 348617711 bytes
Size (rust-1.51.0-powerpc-unknown-netbsd.tar.gz) = 266958089 bytes
Size (rust-1.51.0-powerpc-unknown-netbsd90.tar.gz) = 272438402 bytes
Size (rust-1.51.0-sparc64-unknown-netbsd.tar.gz) = 251407790 bytes
Size (rust-1.51.0-x86_64-apple-darwin.tar.gz) = 282954035 bytes
Size (rust-1.51.0-x86_64-unknown-freebsd.tar.gz) = 274904875 bytes
Size (rust-1.51.0-x86_64-unknown-illumos.tar.gz) = 198895161 bytes
Size (rust-1.51.0-x86_64-unknown-linux-gnu.tar.gz) = 252602702 bytes
Size (rust-1.51.0-x86_64-unknown-netbsd.tar.gz) = 259950675 bytes

and in wip

Size (rust-1.53.0-aarch64-unknown-netbsd.tar.gz) = 241013291 bytes
Size (rust-1.53.0-aarch64_be-unknown-netbsd.tar.gz) = 245435734 bytes
Size (rust-1.53.0-armv7-unknown-netbsd-eabihf.tar.gz) = 211153302 bytes
Size (rust-1.53.0-i586-unknown-netbsd.tar.gz) = 264383887 bytes
Size (rust-1.53.0-i686-unknown-linux-gnu.tar.gz) = 362017076 bytes
Size (rust-1.53.0-powerpc-unknown-netbsd.tar.gz) = 272501050 bytes
Size (rust-1.53.0-powerpc-unknown-netbsd90.tar.gz) = 277785194 bytes
Size (rust-1.53.0-sparc64-unknown-netbsd.tar.gz) = 254650667 bytes
Size (rust-1.53.0-x86_64-apple-darwin.tar.gz) = 298136926 bytes
Size (rust-1.53.0-x86_64-unknown-freebsd.tar.gz) = 287871664 bytes
Size (rust-1.53.0-x86_64-unknown-illumos.tar.gz) = 208714201 bytes
Size (rust-1.53.0-x86_64-unknown-linux-gnu.tar.gz) = 258759631 bytes
Size (rust-1.53.0-x86_64-unknown-netbsd.tar.gz) = 269580000 bytes

so it looks like wip/rust drops support for linux/aarch64 and linux/arm.
I'm unclear on linux/arm vs. linux/armv7, in terms of what arm means
(v4?) and if that actually matters (can it be built now?).

(I'm also unclear on actually building rust on an earvm7hf-el machine,
vs needing a chroot on a high-RAM aarch64, but the question for update
is what's lost, not where we are.)

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index