On Thu, Jun 18, 2015 at 04:06:00PM +0200, Laurent Bercot wrote:
> On 18/06/2015 15:47, Steve Litt wrote:
> >>I expect the dependency chain should be something like:
> >><daemon> depends on: init, <daemon>-sysv-init | <daemon>-epoch-init |
> >><daemon>-systemd-init | <daemon>-openrc-init | <daemon>-upstart-init
> >
> >Whoaaaa, too much for me! Too much for most people. Entangled.
>
> Still, it is an accurate representation of the dependencies.

Now I presume the various init-script packages depend on the init
systems. And if the various init systems mutually exclude each
other, then presumably aptitude has to thread its way through a maze to
find the particular <initsystem> that's already installed and
hence <daemon>-<initsystem> package that's needed. Don't want another
init system installed just because aptitude picked the wrong choice in
the "<daemon>-sysv-init | <daemon>-epoch-init | ..." list.


I assume that aptitude has enough algorithmic capacity to do this, but
when things get complicated there may not be enough computational power
to carry out this analysis in available time and space.

Bow, since its possible to have seeral init systems installedd, and
even to have different subsytems started by different init systems
(not all running as PID 1, of course), perhaps the mutual exclusion
among the init systems is a bad idea.

What is perhaps needed for the <daemon>-<initsystem> packages is for
the package manager do recognise a request that the
<daemon>-<initsystem> package be installed if and only if the <daemon>
package has been installed and the <initsystem> package has also been
installed. This would require changes in the package manager and would
likely delay the devuan jessie release.

Such cojunctive reverse dependencies would bw useful in a lot of other
cases, such as bindings between programming languages and libraries.

But I can't recommend this be done for davuan jessie. Too soon, and it
would make jessie too late.

-- hendrik

> If it
> is too complex, then we need to figure out a way to make it look
> simpler. The average user doesn't need to know what the whole graph
> is, and the packager is supposed to be able to understand something
> as simple as the separation between the mechanism (daemon) and the
> policy (how to start the daemon).
<snip>
>
> --
> Laurent
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng