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

[Pavel Raiskup]

On Tuesday 16 of September 2014 16:41:49 Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Sep 16, 2014 at 04:35:50PM +0200, Pavel Raiskup wrote:
> > 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:

Well, yeah .. :( ok, probably I'm doing something wrong.

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

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

Pavel