On Sat, 30 Dec 2023 07:25:08 -0300
altoid via Dng <dng@???> wrote:

> Hello:
>
> On 30 Dec 2023 at 5:01, Lars Noodén via Dng wrote:
>
> > ... IBM picking up (or being tricked into sponsoring) the
> > decommoditization attack ...
>
> IBM?
> Tricked?
> Right ...
>
> Just like Mike Lynch tricked HP into dropping an absurd 8.0 billion
> for Autonomy to then write off a huge chunk of it?
>
> 8^D !!!!!!!!!!
>
> > ... this new scale at least some minor coordination ...
> I beg to differ.
>
> Not at all 'minor'.
>
> In my opinion, what is needed is Devuan ie: whoever runs the show, to
> clearly define and set a course of action.
>
> And then see that it is followed, to the letter.
>
> To get the idea across in a more graphic manner:
>
> ----------------------------------------------------------------------
> Devuan is *not* a ship safely moored at harbour.
>
> It is a ship with a skeleton crew, barely any fuel in its tanks,
> sailing too close to a reef infested coast with a pack of enemy
> submarines paitiently waiting for it to move into open sea.
>
> It is in dire need of accurate charts and officers (captain/1st
> mate/navigator/engineer) to whom the crew and passengers can look up
> and follow.
> ----------------------------------------------------------------------
>
> > ... many who can contribute with sysvinit scripts ...
> Linux has tens of thousands of very capable users, the great majority
> highly qualified.
>
> There was a post here recently about a script or set of scripts that
> would translate/interpret (?) systemd 'whatevers' to sysvinit scripts
> in a straightforward manner.
>
> If so, that would be *the*' solution.
> If not, I'd say that is exactly what Devuan needs.
>
> ie:
> systemd 'whatever' in ----> sysvinit scripts out.
>
> It must be an *integral and systematic* solution.

Hi,
I fully agree with you and from day one of using Devuan
I'm thinking about what this integral and systematic solution could be.
One proposal was common service description files
for all alternative init systems to share the burden
of maintaining them, there was some interest but
this proposal didn't gain the needed traction.
So thinking about what that solution could be
I have many questions in my head but few answers.

If I understand It correctly one part of init scripts
are included in the initscripts package:

/etc/init.d/bootlogs
/etc/init.d/bootmisc.sh
/etc/init.d/brightness
/etc/init.d/checkfs.sh
/etc/init.d/checkroot-bootclean.sh
/etc/init.d/checkroot.sh
/etc/init.d/halt
/etc/init.d/hostname.sh
/etc/init.d/killprocs
/etc/init.d/mount-configfs
/etc/init.d/mountall-bootclean.sh
/etc/init.d/mountall.sh
/etc/init.d/mountdevsubfs.sh
/etc/init.d/mountkernfs.sh
/etc/init.d/mountnfs-bootclean.sh
/etc/init.d/mountnfs.sh
/etc/init.d/rc.local
/etc/init.d/reboot
/etc/init.d/rmnologin
/etc/init.d/sendsigs
/etc/init.d/single
/etc/init.d/umountfs
/etc/init.d/umountnfs.sh
/etc/init.d/umountroot
/etc/init.d/urandom

and some (let's call it infrastructural) part in sysv-rc

/.
/etc
/etc/init.d
/etc/rc0.d
/etc/rc1.d
/etc/rc2.d
/etc/rc3.d
/etc/rc4.d
/etc/rc5.d
/etc/rc6.d
/etc/rcS.d
/lib
/lib/init
/lib/init/rc
/lib/init/rcS
/etc/init.d/rc
/etc/init.d/rcS

So a first question is: are they enough to boot a system?
At a first glance I don't think so (maybe a very simple system)
and looking at their dependencies just a few other packages
are sucked in.
This minimal sysvinit infrastructure is the one we have
direct control over, with the addition of orphan-sysvinit-scripts
which is a great temporary solution to keep our systems
running but if it is true that there were some 1000+
packages shipping an init script it will not scale up easily.
So the only viable solution to me seems to be to use
systemd's own force, in other words we need to find
a way to leverage their .service files as a base of our init system.
I think that translation like the one proposed
by some scripts to convert .service files to initscripts
(on the fly (dangerous!) or before (needs forking of packages?))
is not a future proof solution as we will always lag behind
to fix breakages created by new features added by the systemd
developers, so in the end only using the service files
shipped directly seems the way to me.
What looks as a great idea at first shows lots of problems
when I start to think how this could be implemented
( maybe just due to my ignorance or partial knowledge):

1) the .service files are mixed with other
     systemd files (.target.wants etc.) and in several directories
     how to the detect the ones  we need?
     blacklist, whitelist? not a KISS solution.....
     maybe by name (skip same name as initscripts?)
     Are there other criteria that could be used?

1a) do .wants.target easily align with initscript's headers?

2) cron.d files are transformed in .timer files so they also need 
     to be fixed

3) /etc/default files are still used but I recall that they will vanish
     in the future

4) systemd runs all services in foreground so the Exec lines
    in service files  miss the needed command line options to
    daemonize a service so all services need to be forked (?)
    in the background by our solution

5) we need to take care of pid files (am I right?)

6) we need to take care of log files (am I right?)

Sometimes I think we are just resisting progress....

Just my 2 cents.

Ciao,
Tito

> > ... getting onboard with that aspect of the development process
> ...
> Needs what I mention above:
>
> "... accurate charts and officers (captain/1st mate/navigator) to
> whom the crew can look up an follow."
>
> Thanks for your input.
>
> Have a Happy New Year.
>
> Best,
>
> A.
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng