Bug#761880: [Pkg-sysvinit-devel] Bug#761880: sysv-rc: support init scripts in /lib/init.d (or similar)

Dmitry Bogatov KAction at debian.org
Fri Dec 21 18:54:32 GMT 2018


control: tags -1 +moreinfo

[2018-12-20 09:15] Ansgar Burchardt <ansgar at debian.org>
> > [2014-09-16 18:00] Ansgar Burchardt <ansgar at debian.org>
> >> The symlinks in /etc/rc?.d/* and /etc/default/* are configuration files,
> >> but init script themselves are not (and if admins are supposed to modify
> >> them, I would call them buggy).
> >
> > Your proposal contradicts Debian Policy (9.3.2):
>
> No, all scripts in /etc/init.d would still be treated as configuration
> files.  Just packages could choose to *not* do that (as is the sane
> way) by shipping init scripts in a different location.

Oh, complications. Here I support previous comment, complications,
shadowing system for little gain.

> Policy also seems to lag a decade behind reality:
> [...]
> 
> It's possible to disable services without editing /etc/init.d/*.
> It's possible to do that without editing /etc/init.d/*. (/etc/default/*)

There are other modifications admin may like to apply. We can't
anticipate them all. eatmydata? nice? unshare? nsenter?

> Allowing packages to not have init scripts as configuration files would
> help dealing with outdated init scripts (from removed, but not purged
> packages) which cause problems (for example when they lack LSB headers,
> have outdated dependencies which cause cirular dependencies, ...).

Yes, there is trade-off. But as I see it, your proposal favors solving
issues of past (missing LSB headers, outdated scripts), which will be
solved eventually, to flexibility of all current and future
installation.

In short: I value possibility to edit /etc/init.d/ scripts and do not
find logic complexity of your proposal warranted.




More information about the Debian-init-diversity mailing list