Re: Removal of firefox115 and firefox128

[Havard Eidnes <he%NetBSD.org@localhost>]

>> I realize that this is quite different from dealing with an age-old
>> language (C) which has been through international standardization in
>> multiple rounds, and which through its actions expresses a vastly
>> different mindset about backward compatibility.  It's ... "different"...
>
> What it's different from is valuing stability.

No contest.

> But it is the world in which we live in, so the question is how to deal
> with it.  I think that's some combination of:
>
>   - 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? :)

>   - 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.

>   - 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...


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...

> 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.

Regards,

- Håvard