On Tue, Sep 16, 2014 at 05:07:06PM +0200, Pavel Raiskup wrote: > > for example > > tmpfiles.d/systemd.conf and tmpfiles.d/systemd-nologin.conf are split > > exactly for the purpose of making it easier to override separately. The > > case of unit files is slightly different, but we really want to have the > > same semantics for all configuration file overrides in systemd. > > Could you please be more specific? You mean that the /usr/lib > configuration should have bigger priority than /etc? There are two independent rules: one is that files with the same name override each other (and /etc has higher priority than /usr/lib), and second that dropins have higher priority than the "basic" configuration files. So to answer your question directly: no, /usr/lib configuration has lower priority, but it might still be visible if not override by a file with the same name in /etc or /run.
> > > > > At least not without a very good reason which would make it worth to > > > > > upset existing users. > > > > > > Oh, yeah - that would not be nice; but the way how it is done now does > > > not seem to be logical (and breaks otherwise nice possibilities) - so I > > > would call it good reason (unless somebody hits me with good reason :)). > > > I'm just not sure who we could upset - do you think there is anybody > > > relying on the current approach? What would be the use case? > > > > > > On Tuesday 16 of September 2014 16:14:16 Tomasz Torcz wrote: > > > > I'd like to ask why dropins are packaged in the first placed? Do you > > > > (Pavel) have some variants of the package that share common unit file? > > > > > > Look at the initial email: > > > | Then I would like to install two service files 'a.service' and > > > | 'a@.service', both hardlinked (ideally). The 'a.service' would diverge > > > | from 'a@.service' just by e.g. > > > /usr/lib/systemd/a.service/50-default.conf > > > | settings. > > > > > > To make it more clear - such service 'a' would have its > > > defaults preconfigured in package; run by `systemctl start a` and > > > configurable 'a@whatever.service'. > > > > So we return to Tomasz'es question: why would you split the configuration > > into two files? > > Oh, I probably missed the purpose of the original question, really sorry > then. The answer: I don't want to maintain the ugly long (configured) > version 'service@DEFAULT.service'. And also it is needed to keep the > compatibility with older /etc/*service files. Some users are already > "including" our default service.service. This is becoming off-topic > the original request, anyway. I don't think that drop-ins are a solutions for this anyway. But the settings from the instance override the settings from the template. Isn't this enough? Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel