Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

specs/config-files: say that drop-ins are not always required #84

Merged
merged 1 commit into from
Apr 15, 2024
Merged

specs/config-files: say that drop-ins are not always required #84

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 18 additions & 15 deletions specs/configuration_files_specification.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -55,20 +55,23 @@ For example, an empty `/etc/foo/bar.conf` means that `/usr/lib/foo/bar.conf` is
masked and thus not parsed.

## Drop-ins
All configuration paths must support drop-ins. Supporting drop-ins means that in
addition to parsing a full configuration file, an implementation also must parse all
files in the drop-in directory associated with it, and merge the result in lexicographic
order. Drop-ins are not full replacements, but must allow specifying a subset of settings
present in the main configuration files.

For example, in addition to parsing `/etc/foo/bar.conf`, `/etc/foo/bar.conf.d/a.conf` and
`/etc/foo/bar.conf.d/b.conf` must also be parsed, in this order.

Drop-ins always have higher precedence than the configuration file they refer to,
regardless of under which hierarchy they are stored.

For example, settings in `/usr/lib/foo/bar.conf.d/a.conf` must override settings in
`/etc/foo/bar.conf`.
All configuration paths must support drop-ins,
except for configuration file formats where automatic combining of multiple files is not feasible,
for example scripts or structured documents.
Supporting drop-ins means that in addition to parsing a full configuration file,
an implementation also parses the drop-in files in the drop-in directories associated with it.

Drop-ins always have higher precedence than the configuration file they refer to.
Drop-ins are sorted in the lexicographic order using the file name without the path,
regardless of the hierarchy under which they are stored.
The drop-ins that are later in this order have higher precedence.

For example, in addition to parsing `/etc/foo/bar.conf`,
`/etc/foo/bar.conf.d/a.conf` and `/usr/lib/foo/bar.conf.d/b.conf` must also be parsed,
in this order.
The configuration in `bar.conf` has the lowest priority,
and is overridden by `a.conf` and `b.conf`.
`b.conf` has the highest priority.

If a config file is masked, drop-ins must still be parsed, unless they are masked
themselves.
Expand All @@ -88,4 +91,4 @@ be supported by implementations. In such schemes many drop-ins are loaded from a
directory in each hierarchy.

For example, `/usr/lib/foo.d/a.conf`, `/usr/lib/foo.d/b.conf` and `/etc/foo.d/c.conf`
are all loaded and parsed in this scheme.
are all loaded and parsed in this scheme, in this order.