On Tue, Oct 17, 2023 at 9:36 AM Simon Lees <sflees@suse.de> wrote:
On 10/17/23 12:49, Neal Gompa wrote:
On Mon, Oct 16, 2023 at 10:16 PM Aaron Puchert <aaronpuchert@alice-dsl.net> wrote:
Am 29.09.23 um 21:11 schrieb Martin Schreiner via openSUSE Factory:
2 - libalternatives does not manipulate symlinks: /usr/bin/alts (the main binary for libalternatives) executes binaries directly (by calling exec()). The actually binary (for example, /usr/bin/vi) is a symlink to /usr/bin/alts, which then reads its configuration files and determines which binary to execute, based on the highest priority.
I would prefer if we could keep symlinks. I don't care where they live, but symlinks are much more restricted and transparent than `exec`:
$ readlink -f $(which clang) /usr/bin/clang-17.0.2
3 - libalternatives supports user overrides: non-root users can override the alternatives by creating their own local preference file in $HOME/.config/libalternatives.conf. This may be done by invoking "alts" directly, as it serves both purposes.
This alone doesn't prohibit symlinks: local overrides could be done via symlinks in ~/bin, and it would still be transparent.
4 - Even if it doesn't manipulate symlinks, groups and manpages are still supported: libalternatives has a "group" directive for manipulating groups of binaries together, and it has some verifications to ensure the binaries in these groups are indeed declared in tandem with one another, essentially managing them as a collection.
This could be an issue in LLVM, because new versions tend to add/remove binaries or manpages. But I should probably migrate that anyway from update-alternatives to GCC-style hardcoded symlinks in the metapackage.
Instead of going straight to libalternatives, maybe we should consider evaluating the usage of alternatives in the first place. "Defaults" metapackages and swappable packages (packages using Provides+Conflicts to ensure one-and-only-one provider installed at a time) are both better options for managing system-wide pointers that RPM supports today.
This is probably a good opportunity to re-asses which packages are using alternatives and whether they still need to. But my gut feeling is it probably doesn't make sense to drop it everywhere.
For example I generally have lightdm and gdm both installed on my machines and some day's I end up switching between a few times as part of testing and i'd prefer not to do this via the package manager.
From a packaging perspective we were also just looking at ImageMagick where alternatives is used for config files and is probably a cleaner solution then using _multibuild to create subpackages with the config in the default location.
The mechanism we use in openSUSE should be ripped out and switched for the systemd unit mechanism. We don't need to make display managers mutually exclusive to avoid the usage of alternatives there. Fedora did this ten years ago when they ripped out prefdm for directly using the display-manager.service unit: https://fedoraproject.org/wiki/Features/DisplayManagerRework -- 真実はいつも一つ！/ Always, there's only one truth!