the problem of rust :-(

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

There is new rust in wip, but updating to it would mean desupporting
some platforms.  Thus the question is how to proceed (post 2024Q2 but of
course we can debate that over the next 3.5 weeks).  It seems options
are:

  1) fix rust so it works on all platforms it works on now

  2) decide to give up on some platforms, withdrawing significant
  amounts of software, and basically turning the hardware into ewaste

  3) see if the issue is buiding vs a built rustc working, and pivot to
  rust-bin that is cross built as the appraoch for some platforms.

  4) version rust, so that the older version is available when the newer
  one isn't.  That also decouples getting it working from newer on
  platforms where it is less troubled.

  Probably, we'd strive to aggressively add versions, and gc versions
  that are not needed for some platform.  Call the oldest necessary
  version the floor version.

  This implies marking packages with required rust version, but we do
  that already.   It then leads to this same problem happening with each
  rust-using program.  Given rust culture, that's probably sooner rather
  than later.  That it turn leads to

     4A) version rust-using programs, and keep the most recent one that
     builds with the floor version

     4B) don't version rust-using programs, so that when something
     doesn't build with the newest version on some platform, it just
     doesn't, leading to using a C ancestor

  5) Convince the rust ecosystem to value portability and to have
  software that runs in a reasonable amount of memory.  Alternatively,
  convince people not to use rust unless their program is already so
  bloated that there is no incremental harm.

Am I missing any?

5 would be the best outcome but given rust culture is perhaps not even
funny.

1 is obviously preferred but seems hard and hasn't yet happened.  Hoping
for 1 doesn't seem like a good strategy.

2 seems unreasonable (given librsvg and py-cryptography; it's ok for
firefox).

3 seems only slightly icky and if it can work seems like the best
approach.  I think we have a lot of cross build support already but I'm
not sure it's all checked in so anyone can just run it.  Yes, it heads a
bit to pkgbin, but that seems better than pkgnull.

4 seems like a bit of work, but just having multiple versions doesn't
really seem like a lot 4A seems like it would be even more work and meet
the goals.  4B may or may not help all that much, but shouldn't be that
hard.

What do the rust people think about 3?

If 3 doesn't work, I think we should head to 4B, mostly so we can get
the decoupling benefit of not holding updates because of some platforms,
with not a huge amount of work.  For example, it seems like aarch64 can
be sorted into plan 1, but not necessarily this week.