Re: Debian systemd survey
Michael Biebl <biebl@debian.org> writes:
> Am 02.06.2013 18:59, schrieb Russ Allbery:
>> There's really no reason to have something like an /etc/default setting
>> for that, the way there is for the rsyncd init script. You can just
>> edit that directly (well, it's systemd, so you have to copy it into
>> /etc and make a new version and then won't know if anything about the
>> default changes -- a truly awful design, but that's another argument).
> You do not necessarily have to copy the whole file. You can
> override/amend the .service file by using a foo.service.d/*.conf
> snippet.
That doesn't really help -- it's exactly changes to ExecStart that I want
to be informed of by dpkg.
Suppose that I modify the systemd file to add an additional command-line
flag, and the package maintainer separately changes the systemd file to
add a different command-line flag. When I upgrade the package, I really
want both flags. dpkg will at least warn me that this happened and show
me a diff, and I can then make the obvious change. With the systemd
configuration strategy, this change is completely hidden to me.
There are many daemons in Debian that are configured with a variety of
command-line options in the package and that the end user will want to
customize with other command-line options without losing the ones provided
by the package maintainer. This is a very common use case, and one that
we frequently handle poorly and awkwardly with /etc/default files right
now and could handle much better with upstart or systemd, except that
systemd's configuration handling shoots itself in the foot.
> As for noticing upstream default changes: There is a tool called
> systemd-delta, which can notify you about such differences.
Does it do the proper comparison? I don't want to just be informed that
my version is different from the default version: I know that. I want to
know if the package file has changed since I based my version on it. This
is exactly the behavior that we get right now from dpkg configuration file
handling. (Ideally, I also want to know *how* it's changed so that I get
a full three-way merge behavior, but that's a harder problem, and only ucf
sort of does that. I wouldn't expect the change in init system to try to
tackle that problem, although of course it would be nice.)
> That all said, I think one has to treat .service files more like
> application ressource files. Having to change them should be the
> exception rather then the norm. E.g., I see the need being able to
> modify /etc/rsyslog.conf, but /etc/init.d/rsyslog (and therefore
> rsyslog.service) not so much.
No, I strongly disagree. This defeats one of the primary gains from
moving to upstart or systemd as I've described at some length in this
thread. One of the points is to get *away* from this broken situation
where the daemon initialization file is an uneditable blob.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: