[Pkg-sysvinit-devel] Bug#781766: sysvinit should depend on initscripts for a functional /lib/sysvinit/init

[josh at joshtriplett.org]

On Tue, May 05, 2015 at 07:24:41PM +0200, Michael Biebl wrote:
> Am 05.05.2015 um 18:19 schrieb Josh Triplett:
> > On Tue, May 05, 2015 at 06:07:56PM +0200, Michael Biebl wrote:
> >> Am 05.05.2015 um 17:57 schrieb Josh Triplett:
> >>> On Tue, May 05, 2015 at 02:08:56PM +0200, Michael Biebl wrote:
> >>>> On Thu, 02 Apr 2015 11:24:53 -0700 Josh Triplett <josh at joshtriplett.org>
> 
> >>> I had assumed that the sysvinit package would stick around as long as
> >>> sysvinit does.  What is your plan post-jessie?
> >>
> >> Drop it, most likely. It has done it's purpose to provide a smooth
> >> upgrade path from wheezy to jessie.
> 
> I have to add here, that I'm not part of the pkg-sysvinit team, so the
> decision is ultimately up to the sysvinit maintainers.

Understood.

> > And drop the mechanism that allows booting sysvinit while keeping
> > systemd as /sbin/init?
> 
> I think this mechanism has value and it's still useful for the other way
> around (systemd + sysvinit-core installed => alternative boot entry for
> systemd). Also, even if the sysvinit package is dropped in stretch, it's
> not necessarily a given, that the user actually uninstalls it.
> 
> So I'd keep this mechanism at least for another release cycle.
> Then again, I'm not the grub maintainer either.

I think it has value in the other direction as well, when systemd-sysv
and sysvinit is installed.  At least as long as we continue to package
and support sysvinit.

> > Personally, in the stretch timeframe, I plan to work on making it
> > possible to remove the initscripts and sysv-rc packages from a systemd
> > system.
> 
> Thanks for your interest in working on that.
> I do hope you co-ordinate that effort with the pkg-systemd team and e.g.
> make sure to user-tag the bugs accordingly
> (suggestion user: pkg-systemd-maintainers at lists.alioth.debian.org ,
> usertag: initscripts-removal)

I've been working on this for a while with systemd folks via IRC and
mail, which led to the masking of the last initscripts scripts.  The
only bug I've filed that's still open is the util-linux bug that you
already know about.

> systemd itself doesn't need any resources from the initscripts package
> to boot a system successfully.

Right; it masks or replaces *every* script from initscripts now.

> A few issues that come to mind
> 
> a/ priority of initscripts needs to be demoted, so it's no longer pulled
> in automatically.

Right.

> b/ /bin/mountpoint binary. Since initscripts is quasi-essential,
> packages can make use of it unconditionally. Solved by moving the binary
> to util-linux. Ongoing (#753779)

Right, that should eliminate the need to keep initscripts essential.

> c/ packages, which added a versioned dependency on initscripts for the
> /run-transition need to drop that dependency. It's no longer needed. MBF
> which probably needs some announcement on debian-devel.

Easy enough.  With that change, nothing except init-related packages
should depend on initscripts.

> d/ insserv needs to be fixed to not barf if the facilities provided by
> the initscripts package are not around and handle this gracefully (by
> simply ignoring them).

Didn't know about that one, but that sounds reasonable.  However,
insserv only makes sense on sysvinit systems, and those systems should
have initscripts, so that might be another path to fixing the problem.

> e/ /lib/init/vars.sh: This shell library is sourced by quite a few init
> scripts (261 according to codesearch) to get some basic SysV settings.
> I'm a bit unsure what to do about this one. I bet, most of them don't
> actually use the variables set by vars.sh, so they could simply drop
> this include. That said, moving it into another package is probably the
> simplest option. sysv-rc looks like a possible candidate.

The few packages using the settings from /etc/default/rcS and similar
via vars.sh should be fixed to obtain them directly.  The only thing
needed by the majority of shell scripts is VERBOSE, and I would suggest
moving that logic into init-functions, since all scripts should be
sourcing that already.

- Josh Triplett