KDE Linux/Banana Split

Splitting a 🍌. Or in our case: making huge changes to the sysupdate.d configs so as to require a hard break version that has to be applied before moving to a newer version.

Also can be used to get rid of compatibility cruft. By forcing users through a specific version we know all updates in that version are applied and by extension we can drop compat logic.

A bit of history: originally we used https://files.kde.org/kde-linux/ as the update location. This very poorly bridged the gap of the rename to kde-linux and eventually fell apart for the rootfsv2 migration. Instead we now do this:

https://files.kde.org/kde-linux/ contains the .raw disk image as well as the associated .torrent
https://files.kde.org/kde-linux/sysupdate/*/ contains all sysupdate artifacts
https://files.kde.org/kde-linux/sysupdate/v2/ and so on are different versions
https://files.kde.org/kde-linux/vacuum.yaml encodes which builds to keep indefinitely (they are called tombstones). it also encodes golden images (i.e. ones we want to keep because they are known to be good)

Right. So. How to make a tombstone? First very carefully think about this problem because it's somewhat important to understand what you are trying to do exactly...

Let's take the example from v2 to v3: We want to create a version in v2 that is the last version so to say. This version's task is to be a v2 version while providing the sysupdate.d changes for v3. Maybe read that sentence until it clicks. The artifacts of the tombstone must look like those of a v2, but the update instructions (i.e. the syupdate.d files) inside the tombstone must look like those of v3.

Here's a handy checklist for the example:

It may be prudent to invent a system that diverts all publishing to a separate root directory until you are absolutely certain the migration is ready. If you push a bad tombstone it'll be very hard to fix things. Currently doesn't exist but technically is as simple as uploading to either a different server or under a different root location.

make sure v2 (i.e. git master) actually works
prepare v3 (possibly in a branch) and maybe test it a bit to make sure the upgrade configs work
be super duper mindful of signing key availability. random branches do not have signing by default!
update upload.sh in the v3 branch to start the v3 update line
make a bunch of v3 builds for testing
make a v2 build with v3 sysupdate.d configs
make a v3 build so as to have a higher version
test upgrade
edit the vacuum.yaml or ask a sysadmin to do it so it marks the v2 (and possibly also the first good v3) build as tombstone (and possibly golden)

Assuming everything went well you should now have: