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. -- 真実はいつも一つ！/ Always, there's only one truth!