Bug#851747: sysvinit-utils: drop Essential flag

[Andreas Henriksson]

Hello Thorsten Glaser,

On Thu, Jan 30, 2020 at 07:17:49PM +0100, Thorsten Glaser wrote:
> On Thu, 30 Jan 2020, Andreas Henriksson wrote:
> 
> > the binary packages built from it where downloaded, checked if it
> > had any init script, if it used vars.sh, and if there was a service
> 
> One of mine popped up, and, while I might investigate into
> writing a systemd service for it,

In my opinion it's just time (well overdue if you ask me) that
/everything/ gets native systemd units. The sysvinit compatibility is
just a compatibility shim. It doesn't give you many of the advantages of
systemd that someone using systemd would expect.

As a "side effect" we also happen to get looser coupling that benefits
this case.

(Also feel free to ask for help mentioning which package it is.)

> I wonder: the use of vars.sh goes along with use of
> /lib/lsb/init-functions (which lintian tells users to add a dependency
> on lsb-base for).
> 
> Would it be absurd to let lsb-base pull in vars.sh?

I don't think that's needed as vars.sh (and sysvinit-utils) is
(and likely always will be) guaranteed to be installed on a
sysvinit(-core) system.

The sysvinit-core, sysv-rc, initscripts packages all declare dependency
on sysvinit-utils already (despite sysvinit-utils being Essential: yes).
And IMHO atleast one of those should stay (after Essential: yes has been
dropped).

> 
> If we did that, would most of these be fixed, or just a
> small amount?

I want less coupling, not more... and on that subject I recently filed a
bug about sysvinit-utils gaining a dependency on lsb-base (making it
pseudo-essential).
Given that exists, it's not possible for lsb-base to depend on
sysvinit-utils as it would cause a circular dependency.

Regards,
Andreas Henriksson