:: Re: [DNG] automatic init script gen…
Top Page
Delete this message
Reply to this message
Author: Hendrik Boom
Date:  
To: dng
Subject: Re: [DNG] automatic init script generation
On Fri, Oct 19, 2018 at 05:05:07PM +0000, zeitgeisteater wrote:
> 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


Looks like a practical way to go about it.

-- hendrik