[tlbuild] running TL24 pretest on OpenBSD

[Mojca Miklavec]

On Wed, 21 Feb 2024 at 06:46, Norbert Preining wrote:
>
> >     the binaries with the version number in the name ("openbsd7.4"
> >
> > Good thought.
>
> I also think that this would be better in principle, but it creates a few problems with
> updates, though:
>         TL2024  openbsd7.4
>         TL2025  openbsd7.6
> are different archs, so updating in place will not work out of the box.
>
> So I am somehow torn what would be better.

I don't know enough about the TL architecture to fully understand what
would be needed in order to support updating in place.
But according to my understanding the question would be equivalent to
the following scenario:
- Install TL on a network drive (or into a folder that's visible by
WSL) using Windows, but also install linux and a few other platforms.
- Try to update/upgrade that installation from Linux (or WSL).

If the above is doable, then in November users could manually install
the openbsd7.6 binaries first, then perform system upgrade, and
finally just change PATH and optionally remove openbsd7.5 after the
upgrade.
Every year TeX Live would start by shipping two sets of binaries (this
year it would be 7.4 and 7.5), in November 7.6 would be added, and
then TL 2025 would remove support for 7.4/7.5 and add support for 7.7.

If you just support one single OpenBSD version and omit the version
number, I'm pretty sure that there will be no way to update in place
either.
- First of all, it would be basically impossible to sync the update of
TL with a new OpenBSD release.
- If you swap the binaries (upgrade OS version) in November, someone
running TL update too early and not reading the mailing list will end
up with a plain broken TL installation with zero warnings.
- If you don't swap the binaries in November, users who diligently
upgrade their OS every 6 months will have a defunct TeX Live for half
a year (if they won't be able to work half of the time, that
distribution will be useless to them anyway).
- Imagine that every user is following the TL mailing list and is
willing to upgrade their OpenBSD version at the same time when TL
swaps the binaries.
  - If they try to update TL before upgrading the OS, they will end up
with broken binaries after upgrade.
  - If they try to update TL after upgrading the OS, their TL binaries
will be broken already. If one is able to upgrade with just perl, that
might work, but if you happen to need another binary like xz[dec],
users will be screwed.

Basically, I cannot even remotely imagine how shipping a single
OpenBSD set of binaries would work at all and what the user experience
would be.
Even if upgrading in place isn't possible, it would still be a lot
less hassle for users to just reinstall TL from scratch after OS
upgrade and get a functional version at any given time than having to
deal with the hassle of version syncs.

Again, it's ultimately Karl's and your decision, but I would vote for
either including the version in platform name or for not supporting
the binaries at all.
I cannot imagine how shipping just a single set of binaries is not
leading into tons of trouble at all fronts.

>From the point of view of how much work that would take: once set up,
it needs one additional commit of binaries every November (assuming
that builds aren't broken). And the same amount of work as any other
platform in the spring.

Mojca

Off-topic:
https://bugzilla.proxmox.com/show_bug.cgi?id=4097