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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
