Contradicting paragraphs about merging vs. masking.

[janc13]

In the Base Directory Specification:

In addition, it must be possible to mask files across different locations in $XDG_CONFIG_DIRS by creating a symlink to /dev/null or an empty file. For example, an empty /etc/foo means that /usr/etc/foo is masked and thus not parsed.

and

A specification that refers to $XDG_DATA_DIRS or $XDG_CONFIG_DIRS should define what the behaviour must be when a file is located under multiple base directories. It could, for example, define that only the file under the most important base directory should be used or, as another example, it could define rules for merging the information from the different files.

… contradict each other.

The latter of those two paragraphs seems more appropriate in a specification like this (leave it up to the applications to define what is desired behaviour for them).

[aplanas]

Maybe they complement each other? The second paragraph seems more generic, but does not specify any masking mechanism that can be implemented by default.

For example, in read-only systems the file /usr/etc/foo cannot be removed by the admin, so creating /etc/foo as an empty file seems a feasible mechanism to indicate to ignore system file. A merge would indicate just the opposite, and use the system file.

[janc13]

Some applications might not work at all with a totally empty configuration.
But you can always override individual settings (all of them if necessary).

Again, it should be up to the individual applications to define the semantics for this (as the second paragraph I quoted says), and the standard could suggest possible solutions for the situation of a read-only /usr but it should not make one way to do it mandatory (which you do when you use the word “must” like you do in the first paragraph I quoted).

Right now you make it impossible for some applications to implement this spec, and that can’t be the intention when you try to standardize something like this, I would think?

[behrmann]

Some applications might not work at all with a totally empty configuration.
But you can always override individual settings (all of them if necessary).

If one can override each individual setting, but don't have to, then it should be possible to run with an empty configuration, because that is the trivial extension of not changing any setting. It is generally preferable to be able to run without any config or to be able to generate once config if it is missing and many programs already do this.

The two sections are not in contradiction to each other, as the former only defines the special case of an empty file or symlink to /dev/null as an explicit escape hatch to overwrite something lower in the hierarchy wholesale. This still leaves open how to handle non-empty files.

[janc13]

Some applications have no defaults compiled in at all, so if you override the default configuration file with an empty one, the application might not be able to do anything (useful).
(Having no built-in defaults has the advantage that you can never have differences between documentation & what is actually compiled in.)

And the two paragraphs in the spec contradict, as in one place it says that not this spec but the application specifies how merging/overriding of configuration files works, while in the other place this spec makes one specific way of doing things mandatory for everyone. Neither place mentions any exceptions.

But there is also no good reason given for why specifically that way of doing things is made mandatory (“must”!), instead of saying that the application should consider this use case when specifying its merging/overriding/masking behaviour (and maybe suggest this method should be used, where appropriate).

[keszybz]

I think the paragraphs contradict each other. I think one is from the original XDG spec, and the other was added later to describe what systemd does. We should decide what behaviour we want, but I think it's better to require the systemd-style semantics.

[bluca]

I need to rewrite these completely - including these features in the XDG spec is not going anywhere, so we should just have a smaller and self-contained, standalone spec for this here