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