Hi all, I would like to introduce to you an alternative for update-alternatives called libalternatives [1]. The main motivation for myself to work on this is that update-alternatives is both too rigid and too simple to actually get the job done. To better understand what I'm talking about, first we have to actually understand what update-alternatives is and how it functions. Some of you may have heard that there is more than one console text editor. Some would have vim installed, and some would have emacs installed and some others may even like to work in nano or ed. The problem arose when some 3rd party program (eg. mutt) needed to edit some file (eg. mail) and then there was no simple way of actually starting this editor. Here is where update-alternatives comes in - it allows each of these program to register as an editor and then update-alternatives would install a symlink to the highest priority editor under /usr/bin/editor. The world was simple. Fast forward a decade or two and today we have various usages of this symlink management system into areas that were never even imagined when it was created. We have symlinks to whole directories. We have multiple versions of python that can be co-installed. And here we come across the first major obstacle and limitation to simply using symlinks -- they only really allow a SINGLE choice to be preferred. Take for example nodejs. You can have nodejs14 and nodejs16 co-installed and running and you could have node pointing to the latter (actually, this is not what happens because precisely of this limitation :-). But, what happens when you run `node14` and then that program re-execs #!/usr/bin/node in a subprocess? The subprocess runs node16 and you are out of luck. You couldn't even compile a binary node module with the older version! What actually happens today is that node stores the major version it executes under in the environment and when /usr/bin/node is executed, it will re-run that version and not the default version -- today update-alternatives still manages node-default symlink. I expect the same issue exists with ruby and python3 and other interpreters but it's not viewed as a deal breaker but an ugly nuisance. Maybe now this can be improved? The second issue that comes up is inability to actually manage preferences on a user level. Imagine you have all editors installed on a multi-user system. The user cannot specify their preferences and must bypass update-alternatives and resort to manual symlink hackery in ~/.bin or similar. The third issue is packaging this mess. How many times have any of you made an error with update-alternatives that then broke an update and became almost impossible to fix without further scriptlet hacks? It's fragile, to say the least. The system is also changed during installation and not at runtime -- this makes it potentially inconsistent between snapshots. Having said all this, my main motivation for developing an alternative is removing the node-default symlink and moving the logic into a library. The /usr/bin/node would link to it and exec the preferred node version based on user preferences, admin preferences and packager preference, in that order. libalternatives provides a single executable - /usr/bin/alts. If you run it, you can use it to change the default preferences. If you executable is simple and does not require additional logic, you can just do a symlink, /usr/bin/editor -> /usr/bin/alts and preferred editor will be run. If you have additional logic, like /usr/bin/node does, just call execDefault(argc) if and when you want preferred alternative executable exec(). At the moment, I've adjusted the packages of various node versions in my home project - home:adamm:alternatives. There is also an example package there [3] that executes either true or false - I hope the file layout is easy to understand. I think I could continue with details, but maybe I'll wait for feedback if anyone finds this actually interesting and worthwhile or maybe never even given it thought until now :-) Cheers, Adam PS. libalternatives is not yet in Factory but should be submitted here in a few days. [1] - https://github.com/openSUSE/libalternatives [2] - https://build.opensuse.org/package/show/home:adamm:alternatives/libalternati... [3] - home:adamm:alternatives/true_or_false