Closed wgwoods closed 1 month ago
It makes sense. I have been thinking about rewriting alternatives to make them more modern, and I even have requirements from other teams as well. The problem is that it was always pretty low on my todo list.
I will try to find someone on our team who would be willing to work on this.
@wgwoods @lnykryn how do I file a request with upstream? In particular nss and p11-kit-trust ?
Is upstream aware of your intended changes or are they going to view these requests as WTF? for the time being ?
@wgwoods The config file idea seems interesting, but why make it compact instead of something more like systemd units (INI-/ConfigParser- style)? That way it's easy to understand and configure.
(also, cc: @thkukuk who is interested in this for openSUSE MicroOS)
I like the idea, but there are some problems, especially with atomic updates as used by different distributions in different implementations, but maybe also with updating configuration files. Please make sure:
For more background and ideas, please look at: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md
If we get this seperated and solved nicely, I will make sure that openSUSE will switch to this alternatives solution. And if we find a more ini style format, SUSE is currently developing a C library to merge such config files for applications, we are currently discussing the requirements of dnf for it with the developers.
@wgwoods @lnykryn friendly ping... Anyone have any idea when this might be tackled?
There's now a library for handling the config file overrides and layering similar to systemd, called libeconf. This is packaged in Fedora already, so this could make it much easier for implementing this.
@Conan-Kudo Well, a lot of people have this on their "when I have some free time" list for years. So I don't expect that this will be done anytime soon.
Background: as part of my ongoing quest to make all RPM scriptlets deterministic, I'm looking for ways to make every common tool that runs in
%pre
or%post
config-file driven rather than code-driven.alternatives
is one of these, and it's one of the few things that doesn't have a config file format already in use. So I'm proposing that either:alternatives
grows its own config file format and drop-in directory, or/usr/sbin/alternatives
.So here's an example of a possible simple config file format:
#
and run to EOLPRIO NAME LINK PATH
PRIO
must be an integer, obviously--install LINK NAME PATH PRIO
+ NAME LINK PATH
--slave LINK NAME PATH
arguments+s SERVICE
--initscript SERVICE
+i
but these are called "services" now)+f FAMILY
(not used above)--family FAMILY
Programs/packages that wanted to install
alternatives
links could ship a config file like, say,/etc/alternatives.conf.d/exim.conf
. The system could then do something liketo perform the equivalent of the
--install ...
commandline, or--remove-from CONF_FILE
to perform the equivalent--remove NAME PATH
action.We could accomplish this by writing a separate wrapper program that parses the config data and translates it into equivalent
alternatives
commandlines, but it seems like this might be something useful to integrate intoalternatives
itself.Does this make sense? Any thoughts, questions, or suggestions? I'll be happy to try to get a patch written to accomplish this if you believe this functionality would be useful.