Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#825937: sysvinit-utils: Please drop startpar dependency

41 views
Skip to first unread message

Sven Joachim

unread,
May 31, 2016, 11:30:03 AM5/31/16
to
Package: sysvinit-utils
Version: 2.88dsf-59.4
Severity: wishlist

With the "init" package no longer Essential, it is possible to remove
init, sysvinit-core, sysv-rc, initscripts and insserv from minimal
chroots. However, startpar remains because sysvinit-utils depends on
it.

Could you please drop the dependency which AFAICS was only necessary for
smooth upgrades from Wheezy to Jessie? It seems sufficient that sysv-rc
depends on startpar.


-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 4.6.0-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sysvinit-utils depends on:
ii init-system-helpers 1.34
ii libc6 2.22-9
ii startpar 0.59-3
ii util-linux 2.28-5

sysvinit-utils recommends no packages.

Versions of packages sysvinit-utils suggests:
pn bootlogd <none>
pn sash <none>

-- no debconf information

Andreas Henriksson

unread,
May 31, 2016, 4:40:03 PM5/31/16
to
Hello Sven Joachim.

On Tue, May 31, 2016 at 05:16:43PM +0200, Sven Joachim wrote:
> Package: sysvinit-utils
> Version: 2.88dsf-59.4
> Severity: wishlist
>
> With the "init" package no longer Essential, it is possible to remove
> init, sysvinit-core, sysv-rc, initscripts and insserv from minimal
> chroots. However, startpar remains because sysvinit-utils depends on
> it.

... and sysvinit-utils is (still) Essential.

This is in my opinion where the focus for changing things should be.
(Making sysvinit-utils non-essential, which means noone cares if
it depends on startpar. You might even discover people have been
working on a plan how that could be implemented.)

>
> Could you please drop the dependency which AFAICS was only necessary for
> smooth upgrades from Wheezy to Jessie? It seems sufficient that sysv-rc
> depends on startpar.

Interesting. Could you please share pointers to back up this claim?

The sysvinit-utils dependency on startpar makes startpar
quasi-Essential. This means anything in the archive can always count on
it being available without a dependency. Given the massive amounts of
(false?) hits on codesearch.debian.net regarding startpar I'd be very
worried to make that change myself.
If you're absolutely confident that dropping this dependency is not
problematic at all, then you should be aware that sysvinit has no Debian
maintainers currently so you could always NMU this change..... better
think (more than) twice about it being safe though before going ahead.

Mainly I don't think it's worth attacking this problem so fine-grained
rather than thinking about the bigger picture.

Regards,
Andreas Henriksson

Martin Pitt

unread,
Jun 3, 2016, 6:20:03 AM6/3/16
to
Hello,

Sven Joachim [2016-05-31 17:16 +0200]:
> With the "init" package no longer Essential, it is possible to remove
> init, sysvinit-core, sysv-rc, initscripts and insserv from minimal
> chroots. However, startpar remains because sysvinit-utils depends on
> it.

Note that this is/would be a critical bug. sysv-rc *must* stay at
least required for now (not essential), as without it, packages that
only ship a SysV init script don't work at all any more as they don't
get enabled. Right now, this is even true for packages that also ship
a systemd unit, but I fixed that recently [1].

Dropping init, sysvinit-core, initscripts, and insserv,
sysvinit-utils, and startpar OTOH is a good direction/move.

> Could you please drop the dependency which AFAICS was only necessary for
> smooth upgrades from Wheezy to Jessie? It seems sufficient that sysv-rc
> depends on startpar.

While sysv-rc indeed contains /etc/init.d/rc which is the place that
actually invokes startpar, this deals well with starpar not being
available:

$STARTPAR -v > /dev/null 2>&1 || CONCURRENCY="none"

So IMHO we should move the dependendy to either sysvinit-core or
initscripts, both of which can be (now or soon) uninstalled on a
system with systemd-sysv. I think moving it to sysvinit-core is
conceptually "more correct".

Thanks,

Martin

[1] http://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=6dd9d53f
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Martin Pitt

unread,
Jun 3, 2016, 6:20:03 AM6/3/16
to
Hey Andreas, Sven,

Andreas Henriksson [2016-05-31 22:30 +0200]:
> ... and sysvinit-utils is (still) Essential.
>
> This is in my opinion where the focus for changing things should be.
> (Making sysvinit-utils non-essential, which means noone cares if
> it depends on startpar. You might even discover people have been
> working on a plan how that could be implemented.)

Right. I just filed https://bugs.debian.org/826205 and will file a
patch/NMU soon, which will allow this to get dropped as well.

> The sysvinit-utils dependency on startpar makes startpar
> quasi-Essential. This means anything in the archive can always count on
> it being available without a dependency. Given the massive amounts of
> (false?) hits on codesearch.debian.net regarding startpar I'd be very
> worried to make that change myself.

I can't quite believe this. The *only* place that should run startpar
is /etc/init.d/rc{,S}, and that correctly falls back to
CONCURRENCY=none if startpar is absent.

In Ubuntu we never supported startpar (it's incompatible with upstart)
and just dropped the dependency without any ill effect.

FWIW, I'm planning to NMU this together with #826205, I'll send a
patch soon.

Thanks,

Martin

Steve Langasek

unread,
Jun 3, 2016, 1:50:03 PM6/3/16
to
On Fri, Jun 03, 2016 at 12:12:43PM +0200, Martin Pitt wrote:
> In Ubuntu we never supported startpar (it's incompatible with upstart)

It's not incompatible with upstart; this was implemented years ago.

Martin Pitt

unread,
Jun 3, 2016, 2:20:03 PM6/3/16
to
Steve Langasek [2016-06-03 10:41 -0700]:
> On Fri, Jun 03, 2016 at 12:12:43PM +0200, Martin Pitt wrote:
> > In Ubuntu we never supported startpar (it's incompatible with upstart)
>
> It's not incompatible with upstart; this was implemented years ago.

startpar doesn't work with upstart "task" jobs. I don't remember the
details any more, but we had to disable it in
https://launchpad.net/ubuntu/+source/sysvinit/2.88dsf-41ubuntu15
as it caused boot lockups.

Anyway, the message to take here was "not installing startpar doesn't
cause any apparent problems".

Martin Pitt

unread,
Jun 3, 2016, 6:40:02 PM6/3/16
to
Control: tag -1 patch

Martin Pitt [2016-06-03 12:09 +0200]:
> > Could you please drop the dependency which AFAICS was only necessary for
> > smooth upgrades from Wheezy to Jessie? It seems sufficient that sysv-rc
> > depends on startpar.

> So IMHO we should move the dependendy to either sysvinit-core or
> initscripts, both of which can be (now or soon) uninstalled on a
> system with systemd-sysv. I think moving it to sysvinit-core is
> conceptually "more correct".

This wasn't correct after all -- sysv-rc can be replaced with openrc
or file-rc, in neither case startpar is needed. So leaving it at
sysv-rc and dropping it from sysvinit-utils is correct indeed.

Trivial patch attached.

Note that I'd like to NMU this together with bug #826205. While this
is just cleanup, #826205 is to avoid breakage once procps gets
uploaded and initscripts' priority gets dropped so that it drops from
the default install.

Thanks,

Martin
0002-Drop-startpar-dependency-from-sysvinit-utils.patch

Martin Pitt

unread,
Jun 8, 2016, 9:40:04 AM6/8/16
to
Hello all,

Martin Pitt [2016-06-04 0:35 +0200]:
> Note that I'd like to NMU this together with bug #826205. While this
> is just cleanup, #826205 is to avoid breakage once procps gets
> uploaded and initscripts' priority gets dropped so that it drops from
> the default install.

I pushed this to git now, and NMUed to DELAYED/5. If/when this lands,
I'll push the release changelog/tag to git too.
0 new messages