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

[Zbigniew Jędrzejewski-Szmek]

On Tue, Sep 16, 2014 at 04:35:50PM +0200, Pavel Raiskup wrote:
> This is reply to both Tomasz and Zbigniew, thanks for reactions!
> 
> On Tuesday 16 of September 2014 16:14:16 Tomasz Torcz wrote:
> > On Tue, Sep 16, 2014 at 03:16:12PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Tue, Sep 16, 2014 at 01:21:30PM +0200, Pavel Raiskup wrote:
> > > > I would expect that parser starts at /etc/systemd/*/*.service, which
> > > > invokes the .include ~> so '/usr/lib/*/*.service is parsed, then
> > > > '/usr/lib/*/*.service.d', then remaining part of '/etc/*/*.service is
> > > > parsed and as the last step, the '/etc/*/*.service.d/' dropins should be
> > > > done.
> > >
> > > This would change the way that drop-ins work. Your model is not
> > > necessarily worse, but dropins have been the advertised way to do
> > > overiddes for a while, and we cannot simply revert the order in which
> > > they are applied.
> 
> This should not be a revert.  Just make it properly defined?
It was already properly defined, maybe just not explicitly documented
for this case. And yes, this is used: 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.

> > > 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?

Zbyszek