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
