Parsing configuration files

Platform
1

Hello,
the Linux Userspace API Group has defined a general format how configuration files should be handled:

A lot of projects already following this convention (pam, util-linux, shadow,…) and we are continuing to adapt other projects too:

Mainly we are using libeconf (GitHub - openSUSE/libeconf: Enhanced config file parser, which merges config files placed in several locations into one.) but we see that a lot of projects are using glib/gkeyfile for configuration file handling.
So, what do you think about adapting gkeyfile in order to fulfill the uapi-group requirements too ? I am just asking if there is an interest about this topic at all before I am staring the development. :wink:
Thank you !

2

What does this mean, precisely?

3

Well, mainly there should be one additional call which parses all files in different directories, merges all values in the defined order and gives one set of data back. Perhaps it is called:
gboolean g_key_file_load_from_conf_dirs (GKeyFile *key_file,
const gchar **conf_dirs,
GKeyFileFlags flags,
GError **error);

The rest of the interface in gkeyfile.h can be used as it is (e.g. g_key_file_get_string, g_key_file_get_boolean,…)

4

But I also open for other solutions :wink:

5

Is there any opinion about it ?

6

Not really sure what problem this is trying to fix?

7

Adding API to GLib is somewhat complicated by the fact that the backward compatibility guarantees on API and ABI are kind of absolute, and that there aren’t many people actively working on the project. Unless there’s a pressing need, or multiple projects implementing the same thing, we do prefer that people open code their proposals first.

I am still fuzzy on what kind of problem you’re trying to solve; reaching out for an API is usually the last step in addressing an issue.

Loading a bunch of configuration files in a set of directories and merging them is not what I consider a “typical” use case—starting from the fact that the key file format was introduced for loading files in a “first location in a search path wins” scenario.

8

Quickly scanning through specifications/specs/configuration_files_specification.md at main · uapi-group/specifications · GitHub it isn’t asking for support for merging config files, just support for looking them up in different directories with priority order, and masking them with symlinks to /dev/null, and supporting drop-in directories.

GLib already has support for priority order using g_key_file_load_from_dirs().

That could probably be extended to support masking with /dev/null without breaking API.

Supporting drop-ins would probably mean adding more API to allow apps to opt-in to it. Probably another variant of g_key_file_load_from_dirs() but with a flags variable.

Feel free to open an issue about it against GNOME / GLib · GitLab. We don’t have the development resources to implement this ourselves in the near future, so help with implementation would be appreciated.

9

Adding more API would be the plan. Perhaps adding a new variant of the call would be enough.
I could do this and have gotten permission from my manager to investigate time for it. I am only asking before I am starting if there is a general an interest from your side on that topic.
I would suggest that I am making a proposal for the API and if it is OK for you, I would start the implementation. My intention is to use already existing code as much as possible.
I have created an “issue” : https://gitlab.gnome.org/GNOME/glib/-/issues/3622

So, would this be OK for you ?

10

Yes please, let’s continue on https://gitlab.gnome.org/GNOME/glib/-/issues/3622

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.