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