[systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include

[Zbigniew Jędrzejewski-Szmek]

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 at .service', both hardlinked (ideally).  The 'a.service' would diverge
> > >  | from 'a at .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 at 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 at 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