Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Ondřej Surý <ondrej@sury.org>]

> On 8 Aug 2019, at 14:08, Philipp Kern <pkern@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ý
ondrej@sury.org