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

[Pavel Raiskup]

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?

> > 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'.

Pavel