On Wed, 17 Jun 2015 09:09:32 +0000
Roger Leigh <rleigh@???> wrote:

> On 16/06/2015 19:47, Anto wrote:
> > On 16/06/15 20:42, Roger Leigh wrote:
> >> On 16/06/2015 18:14, Anto wrote:
> >>> I was not really sure if script similar to update-rc.d would be
> >>> relevant to epoch as the way the runlevel is being managed in
> >>> epoch is different from sysvinit. That is why I am looking for
> >>> other options.
> >>
> >> update-rc.d is an *interface* to update service registration by the
> >> packaging system (or the admin). It doesn't matter if you don't
> >> use rc.d/init.d directories; it's just a name resulting from
> >> historical practice. You *do* need to use this mechanism to
> >> integrate into the system. Ignore its name, and just think of it
> >> as the public interface to the init system service management
> >> (which is init-system-agnostic).
> >>
> >> You can basically ignore the runlevel stuff (it's delegated to the
> >> LSB headers for sysv-rc, so only of historical interest). It
> >> basically has four actions:
> >> - defaults (add [with default runlevels])
> >> - remove
> >> - enable
> >> - disable
> >> So long as you cater for this, that's sufficient. With sysv-rc,
> >> insserv processes the LSB headers for runlevel information and
> >> dependencies; you change them there if you want to adjust them.
> >> epoch can deal with that side of things however it sees fit (it's
> >> entirely an implementation detail)
> >>
> >
> > Thanks a lot Roger for your explanation.
> >
> > However, I still fail understand how to implement what you explained
> > without changing anything on any other packages that have daemons
> > to be managed by epoch. As I mentioned on one of my emails on this
> > thread, the implementation has always been to include the files
> > specific to the init systems into those packages. I still can not
> > believe that this is the only way. Could we not have some kind of
> > man-in-the-middle (I believe the programming term is API) to be
> > used by all packages including the init systems that are totally
> > independent, to talk to each other? I am sorry for those silly
> > questions, but it would be great if you could explains the reasons
> > why the implementation is always like that and the impacts if we
> > would divert from that.
> >
> > I think for me that would also explain why there is no other way to
> > avoid lock-in to systemd rather than forking Debian.
>
> Historically, every new init system (or at least, new in Debian) has
> strived for some degree of compatibility with sysvinit. Both upstart
> and systemd will run traditional init.d scripts, and both plug into
> update-rc.d to act on changes. Had we been able to go forward with
> openrc support, we would have done the same there as well (I think
> patches were made for this already). upstart didn't make use of the
> LSB dependencies; systemd does to an extent but in practice it
> doesn't work as well as it could.
>
> In short, if epoch can't make use of the existing init scripts
> provided by all packages, it's going to have a very big struggle. It
> absolutely must be a drop-in replacement for the existing system in
> order to be viable. There's over two decades of accumulated
> knowledge in the existing scripts (not for all daemons, but
> particularly initscripts and other core scripts). Witness the large
> number of regressions and now unsupported configurations with the
> systemd switch--this is largely due to dropping all that without
> reimplementing it properly. Now systemd will use its own
> configuration files preferentially, and use the init scripts where
> necessary, so from its POV it's a relatively smooth transition where
> individual packages can add systemd units relatively easily. epoch
> much consider doing something similar, since having flag day where
> every package adopts a brand new format is simply logistically
> impractical.

What you say above is true. And what you say above is a catastrophe,
because sysvinit scripts are so crazy complicated that it's useless for
a mere mortal to understand them. The same is true of OpenRC init
scripts.

If Devuan waits for an alternate init that can use those crazy-quilt
sysvinit init scripts, Devuan will still be using sysvinit in 2025.
Nobody, unbacked by the likes of Red Hat, can parse those monsters into
a reasonably concise service definition or script.

The real beauty of Epoch is that its equivalent of init scripts are
very simple, understandable information:

http://universe2.us/epochconfig.html

Here is the sum and total of information that could ever be needed for
an Epoch Object (service, thing, whatever):

===========================================================
ObjectID
ObjectDescription
ObjectReloadCommand
ObjectPrestartCommand
ObjectStartCommand
ObjectStopCommand
ObjectStartPriority
ObjectStopPriority
ObjectPIDFile
ObjectWorkingDirectory
ObjectUser
ObjectGroup
ObjectStdout
ObjectStderr
ObjectEnabled
ObjectRunlevels
ObjectOptions

ObjectOptions is a combination of these:
    RAWDESCRIPTION
    FORK
    FORKN
    PIVOT
    EXEC
    PERSISTENT
    SERVICE
    AUTORESTART
    RUNONCE
    STOPTIMEOUT
    NOSTOPWAIT
    HALTONLY
    TERMSIGNAL
    FORCESHELL
    STARTFAILCRITICAL
    STOPFAILCRITICAL
    NOTRACK
    MAPEXITSTATUS
===========================================================

Most of the preceding can safely be left to its default and remain
unmentioned. Some of it is defined by the LSB header. My point is, by
the time all is said and done, an Epoch object is pretty darn simple,
pretty much like a systemd unit file (which is probably what we
*should* kidnap as our source of conversion data).

So Roger, you're right. But what you say leads to the conclusion that
Devuan will default to sysvinit for a long, long time.

Which leads me to wonder aloud: LSB version 1 is from 2001, and they've
always striven to provide backward compabiblity. In 2001, init was
sysvinit, and sysvinit was init, forever and ever amen. Maybe now would
be the time to break compabitility, ask the daemon authors a series of
questions about backgrounding, process dependencies, environment
dependencies, and the like, and come up with our own definitions that
can be parsed and converted into any init language.

SteveT

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