config files for alternatives?

[wgwoods]

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:

1. alternatives grows its own config file format and drop-in directory, or
2. We write and ship a wrapper that can parse config strings and convert them into invocations of /usr/sbin/alternatives.

So here's an example of a possible simple config file format:

# alternatives config for exim
10 mta              /usr/sbin/sendmail  /usr/sbin/sendmail.exim
+  mta-mailq        /usr/bin/mailq      /usr/bin/mailq.exim
+  mta-runq         /usr/bin/runq       /usr/bin/runq.exim
+  mta-rsmtp        /usr/bin/rsmtp      /usr/bin/rsmtp.exim
+  mta-rmail        /usr/bin/rmail      /usr/bin/rmail.exim
+  mta-pam          /etc/pam.d/smtp     /etc/pam.d/exim
+  mta-newaliases   /usr/bin/newaliases /usr/bin/newaliases.exim
+  mta-sendmail     /usr/lib/sendmail   /usr/lib/sendmail.exim
+  mta-mailqman     /usr/share/man/man1/mailq.1.gz /usr/share/man/man8/exim.8.gz
+s exim

• Comments start with a # and run to EOL
• Each config block starts with a "master" line, of the form PRIO NAME LINK PATH
  • PRIO must be an integer, obviously
  • This corresponds to --install LINK NAME PATH PRIO
• Additional links can be added with lines of the form + NAME LINK PATH
  • These correspond to --slave LINK NAME PATH arguments
• Optional "service" line is +s SERVICE
  • This corresponds to --initscript SERVICE
  • (could also be +i but these are called "services" now)
• Optional "family" line is +f FAMILY (not used above)
  • This corresponds to --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 like

/usr/sbin/alternatives --install-from CONF_FILE

to 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 into alternatives 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.

[lnykryn]

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.

[atodorov]

@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 ?

[Conan-Kudo]

@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)

[thkukuk]

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:

1. user made overrides/changes should not be stored in the distribution provided configuration file, but in another place. Else updating and merging changes done by admin and distribution can become a pain.
2. Don't store distribution provided default configuration files in /etc, there only the changes by the admin should be stored. Makes updating and merging of configuration files, especially with atomic updates, much easier.
   So distributions should store their configuration file in e.g. /usr/share/alternatives.conf.d, which could be read-only, the user made changes should be stored in /etc/alternatives.conf.d and the application merges them at runtime.

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.

[Conan-Kudo]

@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.

[lnykryn]

@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.