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@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to