On Wed, 4 Oct 2023, Richard Biener wrote:
On Fri, 29 Sep 2023, Martin Schreiner via openSUSE Factory wrote:
Hello folks,
As some of you may know, 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...
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.
What we're planning: Replace update-alternatives with libalternatives: https://github.com/openSUSE/libalternatives This change should be done gradually on Factory, and ideally it would require no manual intervention from the users. We plan on releasing this change in batches: i.e.: all Go versions we provide on Factory would be migrated to libalternatives in a single-pass. Then another set of closely-related packages, such as the OpenJDK. Then another, so on and so forth.
What we need: The goal of this thread is to establish a line of discussion around this change, which should be a gradual one on Factory. All opinions, comments, ideas and criticism are valid, and will be taken into consideration.
Status: There are currently 14909 spec files on openSUSE:Factory. 964 (6.46%) of these depend on update-alternatives.
Currently 52 packages use libalternatives, such as vim and nodejs-common. Basically, the cores of both MicroOS and SLE Micro are already using libalternatives.
Things that seem to be clear in this particular context: ... 5 - No RPM macros are required: This is really cool. We're basically just adding a file to %files, to use libalternatives. So no RPM macros are even required here. But we could create an RPM macro that automatically writes the preference file, so we could easily manipulate its contents inside the RPM spec.
6 - How libalternatives can actually be used So there are actually at least TWO ways to use libalternatives: we either create a symlink to /usr/bin/alts, or use libalternatives as a shared object and write a tiny wrapper program, such as this one: https://build.opensuse.org/package/view_file/devel:languages:nodejs/nodejs-c...
The advantage of the first method is that we don't need a special ? albeit short ? C program to act as a dispatcher for libalternatives's magic sauce.
The advantage of the second method is that we don't need packages to depend on the "alts" package (which contains /usr/bin/alts), but only on "libalternatives1" instead (which provides /usr/lib64/libalternatives.so.1).
How does this work when maintaining packages that need to go 1:1 from Factory to old products like SLES 12 SP5 and SLES 15 SPx? Do I need to keep both the "old" update-alternatives piceces in the spec file and the "new" libalternatives one with %if %{suse_version}? Note I also see in binutils
# disable libalternatives for now until it's changed to not # introduce cmake/cunit-tests into the bootstrap cycle %if 0 && 0%{?suse_version} > 1500 %bcond_without libalternatives %else %bcond_with libalternatives %endif
how do we address this?
Were other alternatives to solve the transactional update issue considered, like placing /var/lib/alternatives in /run/ and populating that via some (systemd?) service at boot time from configuration? How does libalternatives solve the issue that its configuration is by definition not restored by rollback either? It only works to roll back when there's no configuration change inbetween? Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)