On Tue, Oct 17, 2023 at 12:40:20AM +0200, Aaron Puchert 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.
Please don't. The hardcoded links are the worst, especially in the cases when binaries are often added/removed. Thanks Michal