:: Re: [DNG] Packages aren't the only …
Top Page
Delete this message
Reply to this message
Author: Anto
Date:  
To: dng
Subject: Re: [DNG] Packages aren't the only path to alternate inits

On 18/06/15 11:29, Daniel Reurich wrote:
> On 18/06/15 10:43, Steve Litt wrote:
>>
>>
>> Yes. I have a suggestion. I suggest we just start assembling a group of
>> Epoch object descriptions for the top 30 most used daemons. Then, as
>> people request them of other daemons, we add those. I suggest we keep
>> these as a group of scripts, *not* as anything the "upstream" has to
>> worry about.
>>
>> Look how this works: In 3 weeks we can have 30 Epoch daemon object
>> recipes. sshd, ntpd, crond, httpd, all the usual suspects. In 3 weeks
>> we've satisfied 80% of the people, with no "help" from the "upstreams".
>> We let people know that if they need an Epoch object description for a
>> given daemon we don't yet support, we'll treat that like a bug report
>> and make such a Epoch object description. As time goes on we'll have a
>> big library of these things, and people will notice that Epoch object
>> descriptions are an order of magnitude easier to understand, and
>> therefore to DIY, as sysvinit scripts. Probably easier than systemd
>> unit files too, given that I've never heard any person describe how
>> systemd actually works.
>>
>> You can have most of your easy Epoch installation, on Devuan, in 3
>> weeks. I have virtual machines, so I can help. It will be fun. And you
>> know what? I might just take each of those Epoch object descriptions,
>> and make a daemontools/daemontools-encore/runit/s6 run file based on it.
>>
>
> I wonder if now is the time to start separating out the init specific
> configuration files, initscripts or service files, libraries and
> binaries out into separate packages so that any particular init can be
> supported without treading on the toes of others. The only issue I
> can see with this is the dependency chain can get a bit hairy.
>
> 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??
>
>


Hello Daniel,

That would be really great, especially if the *now is the time* that you
mentioned is for Devuan jessie. But I think you and other Devuan
developers have already a lot on your plates. And I believe releasing
Devuan jessie with sysvinit was the initial plan and it has the highest
priority. That is why I always use the subject *I* on my emails here,
instead of *we*, because *we* usually implies "we would like to have
that and could *you* please implement that for us" :)

Perhaps after Devuan jessie gains popularity, *we* could start diverting
further from the road that Debian takes.

Cheers,

Anto