[gnutls-devel] GnuTLS | Draft: lib/priority: add a [includes] section and file-optional/file-required keys (!1849)

[Read-only notification of GnuTLS library development activities]

adrien commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1849#note_2005282207


I think file and directory should both be usable at the same time. That being said, in my quick experiment on yesterday, I made it so that the directory one is disabled by default in configure.ac but that's also something I'm very hesitant about and entirely open to change (default would be /etc/gnutls/config.d and it's unlikely that there's already something else there).

Multiple configurations would be treated exactly the same way as if they were concatenated together with `cat`. I think the current implementation with a single file does not treat repeated keys in a specific manner and this wouldn't change. The implementation would simply read all files one after the other, using the same context. I've found that `inih` makes this approach very easy and natural. I'd like to make the testsuite reflect that: prove single-file and split-files configuration are read the same.

This approach has the benefit of not changing the semantics: configuration lines are simply spread over several files. It is possible to introduce inconsistencies and using several files makes this slightly easier because the user may only look at a single file but I believe the scope in gnutls is small enough (a few lines at most) that this won't matter in practice.

My main scenario for this is to allow users to customize their distribution's configuration. That user can do that either manually or by running a tool but in both cases, the affected files do not overlap the ones from the distribution's packages. This is also applies if the main file configuration is empty but a tool manages some files in the configuration directory.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1849#note_2005282207
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20240718/d33606ce/attachment.html>