openSUSE:Update-alternatives migration

This article is a follow-up for a long and intricate discussion on Factory's mailing list.

Understanding the problem

The following problems cannot be avoided indefinitely. We will have to deal with them somehow.

The objective for setting this article up is simple: to get everyone who wants to solves these problems, involved in the decision making, to agree on exactly what is is we're solving, what are the implications for each decision we make along the way, and to avoid miscommunication between different people. In other words, we want to get everyone on the same page.

We can agree or disagree, so long as we understand what we're talking about.

Problem #1

There are some limitations regarding update-alternatives that prevent it from working perfectly when using transactional updates. Basically, /var isn't part of the snapshot's data. This means that all files created/manipulated during package installation in /var/lib/alternatives won't be taken into consideration when snapshots are rolled back.

More information is available here: https://kubic.opensuse.org/documentation/transactional-update-guide/tu-setup.html#tu-setup-var

This fact could lead to broken symlinks:

Suppose I install "go1.20"(snapshot A) and "go1.21" (snapshot B).
I then boot from snapshot A, but "/var/lib/alternatives/go" still tells "update-alternatives" that "go1.21" would be a valid choice, since this information lives outside of the snapshot's directories, in "/var".
If "update-alternatives" were to accept that choice, then "/etc/alternatives/go" would become a broken link, our last line of defence here being how carefully maintained "update-alternatives" is. So that's not a system-level design solution, but rather very application-specific.

Problem #2

update-alternatives uses RPM pre/post install hooks to modify files in /var/lib/alternatives, so it's unsuitable for a image-based operating systems.

Why is it unsuitable for image-based operating systems?

In essence, transactional-update and image based updates are very similar from the requirements, except that image-based has some additional requirements:

no /etc
no RPM pre/post install scripts during installation and update

update-alternatives makes changes in /etc and /var during installations and updates.

With an image based approach, update-alternatives does not work at all, because:

there is no /etc
there is no /var
it cannot be called from pre/post install scripts

Note: The image/transaction is still created by installing rpm packages and running their scripts. There is no problem with using rpm pre/post scripts as such. It is also not required that alternatives are installed specifically in rpm scripts. The main reason for incompatibility is that with current implementation of update-alternatives the alternatives configuration is in a location that is not included in the image/transaction.

Solutions

Migrating to libalternatives

libalternatives ReadMe

Analysis table

The following is a work-in-progress overview of all possible migration strategies, together with their implications.

This table is available here for the openSUSE community to do further analysis based on it, and hopefully, to come to a great conclusion regarding our current usage of update-alternatives, and how we're to deal with the challenges that have arisen from using it.

	Keeping things as they are.	Changing where update-alternatives stores configuration	Replacing all alternatives with RPM conflicts/provides.	Migrating to libalternatives.
Allows for broken symlinks when reverting to an older snapshot?	Yes	No	No	No
Requires parsing special configuration files and performing extra libc or syscalls?	No	No	No	Yes, although the performance impact is minimal
Allows for multiple alternatives to be installed simultaneously?	Yes	Yes	No	Yes
Compatible with transactional updates?	No	Yes	Yes	Yes
Compatible with image-based updates?	No	Yes	Yes	Yes
Requires a new tool?	No	No	No	Yes, might not be a bad thing, is being used for Tumbleweed and MicroOS already
Supports per-user alternative configuration?	No, doesn’t support merging multiple configurations and making a decision based on that	No, doesn’t support merging multiple configurations and making a decision based on that	No, any changes will remove/install packages accordingly	Yes, users may have their own settings in $HOME which override the defaults, but only for them
Supports system-wide alternative configuration? May the admin change the version of the global /usr/bin/perl, for example?	Yes	Yes	No, not easily, we’re basically removing/installing packages	Yes, administrator may override distribution defaults, they’re layered on top of the distribution defaults, without removing those defaults (they simply have a lower priority)
Allows for any files to be changed based on an alternative setting? (binaries, man pages, shared libraries, etc…)	Yes, an alternative impacts symlinks, so it can change anything, such as shared objects, man pages, etc. Only suitable for mutable installs.	Yes, an alternative impacts symlinks, so it can change anything, such as shared objects, man pages, etc. Only suitable for mutable installs.	No, not easily, we’re basically removing/installing packages	No, libalternatives doesn’t change the filesystem after the RPM package is installed
Easy to analyse, understand, introspect?	Yes (it’s all just symlinks)	Yes (it’s all just symlinks)	Yes (it’s all just packages)	Yes, a parameter flag “-l” shows all alternatives and their priorities, taking into consideration every possible configuration file used to make a decision
As of right now(Nov. 2023), would this solution require new packages in Ring0?	No	No	No	Yes, but we can either change libalternatives so it doesn't use Cmake, or check how we'll handle the fact that RPM >= 4.19 requires Cmake as well

Where to go from here

For now, if you're reading this page and interested on this issue, we could keep an ongoing discussion on this very page, through the Discussion tab.

If anything interesting over there pops up, we can update this page here. Hopefully we'll come to a decision at some point.