Hi all,
long time as a silent lurker, but is seems well time to get up and act. Although
today I'm just about writing about doing, so feel free to ignore me.
English is not my first language, so if I use inappropriate writing tone, I
apologize now and please let me know about my errors.
The exchange of ideas on converting init script is needed and I've seen plenty
of interesting comments and proposed solutions.
On 29/11/2019 18:17, s@po wrote:
On Fri, 29 Nov 2019 12:15:29 +0100
Didier Kryn <k...@in2p3.fr> wrote:
Le 29/11/2019 à 02:08, s@po a écrit :
freedesktop.org, should adress the situation,
I don't trust Freedesktop to produce a good quality standard. I
don't know who are the people behind Freedesktop, beyond Gnome and KDE,
but they have produced Dbus and also the practice to automatically
create unwanted directories in your home, unless you disable them
explicitely.
If "unit" files are something which can be retained (after all,
there might be one non-negative outcome of Systemd), they can be used to
produce init scripts for various init systems, or these init systems
could be made able to, optionnaly, read their configuration from "unit
files".
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 don't trust them neither..
But, they should have addressed this problem after all they were waving the
flag of standards..
They seems to forgot a Standard Init API mechanism.. shame..
I spoke about that because I took 5 minutes to look at last development of
SysVInit, and indeed you find there some stuff about systemd and dbus
integration..
I understand the dbus integration as a way, so that SysVinit daemons could
coexist with Dbus controlled daemons..
The Idea arrived..
Why not have an Interpreter, for the UnitFiles, that then internally do things
as SysVInit does?
In this way we could preserve SysVinit daemons functionality, and when impossible( or a
"unscallable wall arrive".. ), SysVinit will continue to control, the usual
daemons, plus the wave of non SysVinit ones( in the mean time we could have time to port
daemons at the speed we can.. ).
So this idea is some sort of a patched SysVinit, to have half of the 'Script
Injector' idea( the interpreter of unit files part ), and some logic to do it
like sysVInit does..
But that would also means.. that we had to have in /etc/init.d/, all the s*tty
systemD service files.. which is a bit crazy..
Fascinating, but I'd like to explain my viewpoint about this idea.
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.
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.
Best Regards
Massimo
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
