On Thu, Jun 18, 2015 at 09:47:21AM -0400, Steve Litt wrote:
> On Thu, 18 Jun 2015 21:29:36 +1200
> Daniel Reurich <daniel@???> wrote:
[snip]
> > And if each of those <daemon>-*-init packages depended on their
> > respective init system, and each of those init systems provide the
> > virtual package "init" (as is the case in Debian and Devuan Jessie),
> > then apt should be able to work out that when installing <daemon>
> > that because sysvinit-core is the package providing init that it must
> > also install <daemon>-sysv-init in order to satisfy the dependency.
> > The problem is whether changing init systems would result in pulling
> > in the new <daemon>-*-init dependency required for the new init
> > system.
> >
> > Thoughts??
>
> My thought is there are some packaging tasks better done by a five step
> README doc. All this package dependency described in this email is an
> example. Instead, just have one package that installs Epoch, with the
> epoch program in /sbin. Have another package that puts common
> Epoch daemon defs in a directory, ready for copying and pasting. Just
> because one installs Epoch doesn't mean he wants to blow off sysvinit.

> One more thing: There are *huge* benefits of being able to choose your
> init, at runtime, just by changing your Grub or LILO init= value.

I agree on that last point; booting with init=/bin/sh has helped me fix
a system more than once.
Also, it can be handy to switch between a known-good init and an
experimental one.

Honestly, the overhead of simply having another package is probably
going to be at least as great as the overhead of installing scripts
for all init systems, and will be paid in part by everyone:
* the repository index gets larger
- more disk space and bandwidth from the mirrors
- more disk space and bandwidth required for the systems
* the dpkg/apt package database gets larger
* it gets harder to manually upgrade/downgrade packages
* it gets harder to switch inits, due to the maze of initscripts
that will need to be installed for each new package

I see some comments that seem to assume that every init script should
imply a dependency on the corresponding init system.
A dependency is for a package without which the package would be
unusable for its normal use (IIRC).
If you use runit with a daemon that supports upstart, runit, and sysvinit,
running /etc/init.d/<script> is not part of your normal use; there is
no reason to depend on sysvinit except perhaps this way:

Recommends: sysv-rc | upstart | runit

As far as quantity of work goes, you may need to do more than just 30
daemons to get a moderately featureful desktop going.
But maintaining the scripts separately is probably going to be easier
than adopting each of the packages.

You won't be maintaining scripts for all 1000+ packages:
epoch users probaly won't want heartbeat, or the three UPS packages.

If you do maintain scripts for separately maintained daemons,
mark your packages as enhancing them.

HTH,
Isaac Dunham