Am 21.09.21 um 09:47 schrieb Danilo Spinella:
libalternatives is imho a big improvement over update-alternatives.
But the question remains: what about performance? If I have a small program that is called in a loop, is performance severely hampered? I.e. how does the following a=`cat <<EOF for ((i=0; i<10000; ++i)); do awk 'BEGIN { print "hallo" }' done EOF` #> time -c "$a" >/dev/null perform with libalternatives in contrast to /usr/bin/gawk?
Is there any plan to upstream its support? I think the Open Source ecosystem would greatly benefit from doing so and we wouldn't have to maintain libalternatives support for the packages. Plus, I am a big fan of upstreaming and letting the spec file just run make && make install.
Let me know if you need any help regarding this.
Regards, Danilo
On Mon, 2021-09-20 at 09:19 +0200, Stefan Schubert wrote:
Hi,
most of you are already familiar with the usage of update- alternatives. Update-alternatives, at its core, is a symlink management system. This system is then mostly used as means for administrators of a system to select a default application. For example, if we have vim or emacs installed, the admin can then make one accessible as an editor application. Update-alternatives manages these tasks by symbolic file links which has worked out, that it could become quite instable in older updated systems. Adam Majer has established a new concept how to handle the update-alternatives tasks: libalternatives Libalternatives does not use file links anymore but little configuration files which is much more stable and quite easy to handle by the administrator. Have a look to https://github.com/openSUSE/libalternatives for more information. One additional benefit of libalternatives is that it does not create entries in the /etc directory anymore. In the future the /etc directory will be used for entries/changes ONLY which have been done by the administrator and do not belong to packages or have been created by package installation.
I have already switched about 40 packages to the new libalternatives which we need around MicroOS and have submitted it to factory.
This list includes a lot of python packages. Python packages are using nice RPM macros for handling update-alternatives stuff. Currently the fixes are made manually in the spec files and it will not be done by macros anymore. I have done this step at first in order to get a feeling what is needed for using/updating these macros at first. Now I will patch the alternatives macros or will write new one in order to simplify it again. And yes, I will update the regarding python packages again. So please, do not panic :-)
Please inform us if you have any comments, suggestions or even doubts.
Greetings Stefan
-- ********************************************************************* ********** Stefan Schubert e-mail: schubi@suse.de --------------------------------------------------------------------- ---------- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany
(HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer