On 09/16/2014 01:16 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Sep 16, 2014 at 01:21:30PM +0200, Pavel Raiskup wrote:
Hi,
consider the situation that admin has /etc/systemd/system/a.service, which
includes via .include the /usr/lib/systemd/system/a.service. Then in our
case there exists also packaged /usr/lib/systemd/system/a.service.d/ with
existing drop-in. In this case - the setup from /etc/ is beaten by
drop-in files from /usr/lib. Reproducer is in Red Hat Bugzilla [1].
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. At least not without a very good reason which would
make it worth to upset existing users.
The problem which was pretty obvious was going to happen when dropins
got added and now is causing confusion and even breakage ( think mix
match of combinations of ways to overwrite ) is that we need to reduce
the means you can overwrite existing unit files to one and deprecate the
other ones.
Bottom line we should only have one way to do things to keep things
simple not three not five not fifty.
JBG
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
