On 22/06/15 23:58, Daniel Reurich wrote:
On 20/06/15 05:14, Hendrik Boom wrote:
On Thu, Jun 18, 2015 at 09:29:36PM +1200, Daniel Reurich 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
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??
If you're happily running with epoch, and you install a daemon
that happens not to have an epoch init package yet, the only way to
resold the matter might be for aptitude to switch your entire
machine over to sysv-init because it does have a sysv init
package.
Or worse, It might find a systemd init script :(
That is likely not what you want. You might want the opportunity
to cook your own epoch init script, packaged or not.
Depending on `a|b|c` doesn't imply an exclusive or, just or, so I'd
expect that provided the dependencies for a and c are met, both a and
c will be installed unless either those packages or their
dependencies would declare an explicit Breaks or Conflicts against
each other which makes co-installation impossible.
Thinking the dependency graph through a bit further though to allow
the side by side installations of init systems, this can be
achieved: - Provided no dependency conflicts, we'd either need a
symlink or possibly hard link to link /sbin/init to the default init
program - so this should probably be provided by a package - lets say
init-default-<init system name> which should declare a Breaks with
all the other init-default-<init system name> packages. - Each
respective init system core package should recommend their own
respective init-default but not depend on it.
Of course to complete the set each init-default-<init-system name>
should depend on the package containing the actual init binary.
--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
