On Tue, 3 Dec 2019 08:58:10 +0100, Denis wrote in message
<20191203075810.twxmme6ayyccbftf@reflex>:

>
> dear Massimo,
>
> you are very welcome :^) I'm happy to see here a fellow VUA :^D
>
> down to business

..thanks for talking good sense here, Denis and Massimo. :o)

>
> > If (assuming that) we are going to lose the source of init scripts
> > upstream, then it's the only way forward. (For those who consider
> > recognizing the unit files as a valid source a defeat: I may agree
> > with you, but sometimes a strategic retreat can lead to victory).
>
> I agree, but more than a defeat, this is a repairing strategy against
> an hostile move. Those involved in Debian and SPI should acknowledge
> they are being hostile to the UNIX community at large.
>
> About having "an Interpreter, for the UnitFiles, that then internally
> do things as SysVInit does": I have privately experimented with this
> for a while now and there are corner-cases, but it is feasible, if
> such cases can be taken care of.
>
> You adress very well this issue with your reasoning:
>
> > My impression is that it is viable building a batch init script
> > generator, where package maintainers are able to check and validate
> > the newly generated init scripts *in the maintainer test system*, as
> > well as take care of any peculiar bug of the translation, or quirky
> > behaviour of the unit files.
>
> This would mean having two things at least:
>

> 1. a DSL parser for the conversion of unitfiles to shell scripts
>    say "systemd2sysv".

>

> 2. an easy way to test the shell scripts generated, which is also
>    crucial to the task: the quality of the testing environment.

>

> 3. optionally, a way to repackage and test semi-automatically an
>    existing deb package undergoing this conversion.

>
> I have experience writing DSL parsers and recommend using either:
>
> 1. stb_c_lexer by Sean Barrett, part of the STB C lib collection
>

> 2. libhammer by Meredith Patterson, part of langsec.org
>    more complex, but way more secure, not sure if this level of
>    security is needed however

>
> Assuming of course whoever writes this likes to make it in C, which
> I'd recommend.
>
> I wholeheartedly agree with all your reasoning, quoted below. I don't
> think that converting automatically at init or at package install is a
> good idea: we need to keep this process under scrutiny by maintainers,
> hoping more people will help Devuan, at least on converting scripts
> for important packages, and make life easier for them.
>
> > As it's systemd we are talking about, I wouldn't ever place a bet on
> > stable and documented behaviour on its part. Otherwise we wouldn't
> > be here on devuan ML, after all. When new peculiar behaviour is
> > discovered, we can adapt the initscript generator. This would mean a
> > huge effort on repacking debian packages, or having blanket-like
> > packages with init"scripts" for SysV/openrc/any_init that provide
> > the init support to all/groups of debian packages, possibly synced
> > with major revisions of devuan.

..my observation from the few .src.deb and .deb packages I've looked
into, is we have 2 kindsa DDs, our friendly DDs keep upstream init
scripts intact in their src.debs and builds their .debs according to
the current Debian doctrine, some even allow in the upstream or
debianised init scripts to try support alternative init systems in
Debian, while the systemd crowd throws out all non-systemd upstream
init system support to make both their .src.deb and .deb packages,
systemd-only.
Some of these systemd folks may be doing the tactical thing of keeping
the upstream init support appearance.

..bottom line is, we need to look upstream.

..another tool we have, is alien, that could use some TLC, allows us
to look sideways to e.g. good old Slackware.com ;o)

> > On the other hand, a unitfile *interpreter* is a different story,
> > I'm not sure this is viable as of now, and the risks look greater to
> > me in this case. IMO there are two scenarios.
> >
> >
> > 1) the interpreter is external to SysVinit/any_init init and is
> > called after each package update (by means of apt ?). Still, any
> > bug that creeps through by leveraging unexpected unit file behaviour
> > will risk of breaking the interpreter *in the devuan user system*,
> > and this would negatively affect devuan reliability. Imagine the
> > backfire of a situation where the interpreter fails after a security
> > update for some obscure change in a unit file, so at service
> > start/stop or at next reboot the system goes astray.
> >
> > 2) the interpreter is run by the init process (bound to it some
> > way) and used each time a script is accessed. I'd rather not see
> > this, more complexity of this kind in the init process is bad for
> > system health.
> >
> > I agree the interpreter idea is technically intriguing, but bot
> > scenarios are a bit too close to reimplementing systemd, IMO. I'd
> > rather develop something useful to the mantainers now, and keep the
> > option to turn it into a package for the end user later on. So I'd
> > first go with 1) the offline translation, 2) get it stable enough
> > that it can run automatically on any debian package updates, 3)
> > monitor the amount of bugs and manual corrections needed, then 4)
> > enable the initscript to be automatically generated and added to
> > packages in devuan, 5) monitor again for errors 6) consider putting
> > the interpreter in the final system.
> >
> > We can have both solutions along this path but I think the solution
> > with shorter development time and biggest advantage to maintainers
> > should be prioritary.
>
> many thanks
>
> ciao


--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.