On 2018-10-17 11:29, Hendrik Boom wrote:
> On Tue, Oct 16, 2018 at 06:05:21PM +0200, Enrico Weigelt, metux IT consult wrote:
> >
> > I personally, got tired of inventing yet another init system - did that
> > over 20 years ago (actually, some things not so different from *early*
> > systemd - before they became totally nuts).
> >
> > The problem, IMHO, isn't so much creating an init system, but
> > maintaining the corresponding config/scripts for all the packages.
> >
> > One thing we perhaps could do is inventing a small declarative meta-
> > config language for certain common service types / usecases, so we
> > could automatically generate a large portion of the scripts/config
> > automatically for many init systems.
>
> As long as it doesn't metastatize into yet another thing like
> systemd unit files, incompatible with everything else.
> I realise that avoiding that is what you're proposing, but it's worth
> emphasizing.
> Systemd's unit files may well contain the information we need, but it's
> mot clear to me that their specification is stable enough for our
> purpose.
>
> I wonder if the right place to start is to write some kind of text
> processor that looks through existing init scripts lookinfg for
> similarity and difference, and then sorting out which differences are
> important and which similarities are copied bugs.
>
> -- hendrik
>
I'm looking at unitfile -> sysvinit conversion for a remaster project of mine.
The scope is narrow in my case, but I'm curious if it could scale enough to be
useful. Like... convert the bulk of standard service management and
automatically detect weird edge cases for manual review... (e.g. dumping them to
file as "interesting, weird, please check me..."). It would likely be a net gain
over trying to get raw manpower to handle every single package always.

Maybe take this an inch at a time so it doesn't metastatize. Enough to be useful
but no more (especially not enough to become its own stand-alone PITA).

- ZE