Re: Removal of firefox115 and firefox128

[Greg Troxel <gdt%lexort.com@localhost>]

Havard Eidnes <he%NetBSD.org@localhost> writes:
>>   - attempt to land rust updates early in the quarter, rather than it
>>     being an emergency at the end.  I know that's work.
>
> I thought we were already at this point? :)

We are on "attempt".  We are not longer early in the branch and pkgsrc
is at 1.91.1.  In wip we have 1.92 and 1.93.  I have the impression it
would be good to land 1.93 and there is an llvm version mismatch issue,
pkgsrc being at 19 and not 20.  Or maybe there isn't, and it would just
be use-internal?

So if we think 1.91.1 for the branch is the right answer, we're on plan.
If we think the answer is 1.92 or 1.93, then 3/1 is coming soon.  I
haven't seen a call to "please test X because we want to land it in
pkgsrc really soon".

I know you're doing a ton of work and I'm merely suggesting that we get
more people involved in testing, which usually only takes a specific
request.

(A reminder that I'm no longer on PMC, and I'm not managing the next
branch, so this is just commentary from another pkgsrc developer.)


>>   - be prepared to give up on marginal arches for rust, and concentrate
>>     on amd64, aarch64, i386, earmv7hf-el, and consider having a working
>>     rust-bin good enough for the 32-bit arches
>
> Well, so far, in addition to the above we also have mips (w/mips32
> instruction set variant, with binary only, mostly due to user-space
> virtual memory restrictions), powerpc (32-bit, self-hosts), riscv64
> (self-hosts), earmv6hf-el (binary only), aarch64_eb (self-hosts),
> and now that Jason has fixed the pmap on m68k, I'm eyeing whether
> that's also a possible target (probably binary only, we'll see).
> Another possibility which should not be too difficult is big-endian
> 64-bit mips.
>
> In all these cases I'm of course relying on the given CPU
> architectures already having support in both LLVM and rust, so the
> target adaptation becomes a surmountable task for a hobbyist.

I was trying to separate  the concepts of

  - somebody wants rust to work on some older/odder CPU and does the
    work

  - because it worked once, we now won't update until it works


The point I was trying to make is that I'm concerned that up-to-date
rust for mainstream platforms isn't happening because of a bunch of
older/odder (perhaps retrocomputing) platforms.

>>   - think hard about verisoning rust, so we have multiple versions all
>>     the time.  Don't worry that some programs won't work with the newest
>>     version available on some arch.  Just let people deal as best as
>>     they can.  This is a decision to not let difficult arches hold back
>>     the rest, and if there is willingness to fix the hard ones great,
>>     and if not they'll lose the ability to compile some programs.
>
> In some sense in pkgsrc-wip each new rust is "versioned", but at any
> given moment you can only have one of them installed.  For main
> pkgsrc I have not even thought about doing "versioning", or what the
> implications would be...

Yes, I was trying to bring that up.

One strategy would be to just have rust191 rust192 rust193 in pkgsrc,
with BROKEN_ON adjusted appropriately.  You could, just like wip, only
install one.  The rust.mk could choose the most recent one that works,
for any platform.  The win would be that amd64/aarch64 and rust-bin for
more could get recent rust faster.

The problem would be that then we'd be at "I want to update foo-rs and
it works with 1.93 but not 1.91, so if I do it will break on mips.  Can
I do that anyway?"

There's a further step which is to version them like gcc.  That would
let firefox115 depend on old rust.  We could also not do this, have
firefox115 depend on old rust, and have the build work only if that rust
or no rust is installed.

All of these things seem like an improvement from where we are.
>
> Returning back to firefox115, according to
>
>   https://firefox-source-docs.mozilla.org/writing-rust-code/update-policy.html
>
> one would have to resurrect a rust versioned between 1.66.0 and 1.69.0
> in order to have the best chance of being able to build it.  And
> that may not be the only dependency which needs to be back-dated in
> order for the build to produce a usable result...

Well in that case, it doesn't really seem like a good idea.  (I am not
clear on why people want to run 115 anyway - am guessing there are
systems where 115 worked but no newer can be built.)

>> I'm finding that things used by Home Assistant want bleeding edge rust.
>> So far I was able to pull rust-bin from wip onto my 2025Q4 system and be
>> ok, but things don't feel stable.  For this I only care about amd64
>> today, maybe aarch64, and some day in the glorious future risc-v.
>
> I've not taken the leap into the Home Assistant ecosystem, so can't
> report any similar experiences, sorry.

It's not really about HA -- it's just that many programs out there want
really recent rust.   I had to update beyond what was in stable but I
don't remember exactly when.   Just pointing out that there is so much
demand for unreasonably recent versions that it pushes me to want to
have recent rust on amd64 at least.

But, I'm building for me, and using pkgsrc-current or wip has been
workable.