On Thu, 18 Jun 2015 21:29:36 +1200
Daniel Reurich <daniel@???> wrote:

> On 18/06/15 10:43, Steve Litt wrote:
> > On Wed, 17 Jun 2015 21:27:21 +0200
> > Anto <aryanto@???> wrote:
> >
> >>
> >>
> >> On 17/06/15 17:37, Steve Litt wrote:
> >>> Hi all,
> >>>
> >>> After the recent discussions, I'd like to point out that packages
> >>> aren't the ONLY path to alternate inits. I've personally
> >>> demonstrated that with SucklessInit+daemontoolsEncore,
> >>> SucklessInit+s6, runit, and Epoch, it's quite doable to download,
> >>> build, and install these things in parallel to each other.
> >>>
> >>> I fully endorse the effort to put alternative inits in packages.
> >>> It would be wonderful to have, for instance, an Epoch package that
> >>> "just works". I also endorse those individuals who go the
> >>> out-of-package route.
> >>>
> >>> Thanks,
> >>>
> >>> SteveT
> >>>
> >>> Steve Litt
> >>> June 2015 featured book: The Key to Everyday Excellence
> >>> http://www.troubleshooters.com/key
> >>>

[snip]

> >
> >
> > 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.

Why not leave sysvinit just how it is? It works. It's been working for
20 years. My suggestion was a big box of Epoch defs, and a big box of
Daemontools[-encore] runscripts, and a big box of s6 runscripts, and a
big box of runit runscripts.

apt-get install epoch-scripts

The preceding just lays down the Epoch defs somewhere from which you
can copy and paste them. Or, if somebody is cool enough to write a
program, the program can copy and paste them.

The same would be true, respective of init system, for s6-scripts,
daemontools-scripts, and runit-scripts.

Amount of work: Minimal
Amount of rework: Zero
Toes stepped on: None
Extra work for "upstreams": Zero

This might start out as a 100% user driven thing, with the user copying
and pasting according to a README file. Later, as we have success with
it and understand the nature of automation needed by the user, we can
provide programs to automate it, right alongside the big box of
scripts. By slowly progressing from user-driven to automated, we can
get *something* out there quickly. Think of it as agile packaging :-)


>
> 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

Whoaaaa, too much for me! Too much for most people. Entangled. Leave
OpenRC, Upstart, systemd and sysvinit alone: They already work (well,
except for systemd). If the user wants Epoch, just give him the tools
for Epoch, and leave the rest where it sits. Same with
daemontools-encore, s6 or runit.

>
> 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??

My thought is there are some packaging tasks better done by a five step
README doc. All this package dependency described in this email is an
example. Instead, just have one package that installs Epoch, with the
epoch program in /sbin. Have another package that puts common
Epoch daemon defs in a directory, ready for copying and pasting. Just
because one installs Epoch doesn't mean he wants to blow off sysvinit.
One more thing: There are *huge* benefits of being able to choose your
init, at runtime, just by changing your Grub or LILO init= value.

You know, I used to be an "upstream" (VimOutliner). My co developers
and I used to joke about how Debian's package invariably turned a
simple concept of a few copy commands into something that often failed
and left us no clues with which to troubleshoot. And of course there
was Debian's steadfastly changing the very essential Vimoutliner
command keystroke to something MUCH more time consuming. As a first
troubleshooting measure, we started recommending to Debianists that
they install direct from our tarball, following the instructions in
that tarball. 80% of the time that fixed the problem, and the other 20%
it made it trivial for us to go in and troubleshoot.

I think we should always make sure packaging makes things easier, not
harder.

SteveT

Steve Litt
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key