dear Massimo,

you are very welcome :^) I'm happy to see here a fellow VUA :^D

down to business

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