> On 8 Aug 2019, at 14:08, Philipp Kern <pk...@debian.org> wrote:
>
> On 2019-08-08 13:47, Ondřej Surý wrote:
>>> Please stop hating on sysvinit
>> So, just to clarify… so, it’s ok to hate systemd, but it’s not ok to
>> hate sysvinit (spaghetti of shell scripts)?
>
> I don't think that's a constructive line of argument.
Maybe, but the email subject seemed too ironic to just let it be.
> At the same time it's not a race to the bottom in terms of features. I think
> our baseline should be thinking in terms of the features of the default we
> have.
And there’s the problem. If we keep with sysvinit as a baseline of features
provided by the init, we end up with just every init script having something
like this:
do_tmpfiles() {
local type path mode user group age argument
if [ -r "$1" ]; then
if [ -x /bin/systemd-tmpfiles ]; then
/bin/systemd-tmpfiles --create "$1"
else
while read type path mode user group age argument; do
case "$type" in
d)
mkdir -p "$path";
chmod "$mode" "$path";
chown "$user:$group" "$path";
;;
\#*)
;;
*)
log_warning_msg "tmpfile.d type '$type' is not
supported yet"
;;
esac
done < "$1"
fi
else
log_warning_msg "tmpfiles.d file '$1' doesn't exist or is not readable"
fi
}
> I don't have a great answer about the added maintenance cost that sysvinit
> support puts on maintainers and thus they are rejecting certain changes. I
> would like to say that I appreciate the work but personally not care, but I
> have learned the hard way that just keeping things working is a ton of work.
> And if you don't pay that cost stuff keeps rotting. Some of that could be
> addressed with better integration testing. But at the same time it does not
> answer the question on who pays the cost of rebasing changes, especially with
> more upstream packages providing base services building more around reliable
> systemd services. I feel like the answer is temporarily throwing out those
> parts if needed or accept that they are broken until they get fixed, but that
> might not be universally accepted, I guess.
The problem here that “sysvinit” or “systemd” are vague terms. For some
packages, sysvinit really means sysvrc, for other packages systemd means much
more than just the service script (service activation, isolation, etc…) which
is hard to mimick without systemd and friends. For yet another group of
packages (postfix, cyrus-imapd), it could have meant not having to develop own
supervisor and just plug it into systemd.
All my packages still have sysvrc scripts, but it’s easy to dislike maintaining
sysvinit script when you look at the difference:
6 pkg-dns/bind9-9.14/debian/bind9.named.default
145 pkg-dns/bind9-9.14/debian/bind9.named.init
vs
6 pkg-dns/bind9-9.14/debian/bind9.named.default
16 pkg-dns/bind9-9.14/debian/bind9.named.service
1 pkg-dns/bind9-9.14/debian/bind9.named.tmpfile
And I can certainly understand why the maintainers would reject big patchset
for policykit - the maintenance burden is not “hey, accept this patch”, but
they would have to take care of the patchset every time something breaks, or
there’s security issue. Diverting too much from the upstream has
non-negligible risks.
Ondrej
--
Ondřej Surý
ond...@sury.org
