Autore: Daniel Reurich Data: To: dng@lists.dyne.org Oggetto: Re: [DNG] Packages aren't the only path to alternate inits
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.