-
Notifications
You must be signed in to change notification settings - Fork 25
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.
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
Contradicting paragraphs about merging vs. masking. #49
Comments
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. |
Some applications might not work at all with a totally empty configuration. 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 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? |
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 |
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). 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). |
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. |
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 |
In the Base Directory Specification:
and
… 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).
The text was updated successfully, but these errors were encountered: