On 2023-07-29 14:33:28, tito via Dng wrote:
> On Sat, 29 Jul 2023 21:23:27 +1000
> onefang <onefang_devuan@???> wrote:
>
> > On 2023-07-29 08:13:22, tito via Dng wrote:
> > > On Sat, 29 Jul 2023 14:30:36 +1000
> > > onefang <onefang_devuan@???> wrote:
> > >

> > > > On 2023-07-29 08:18:54, Alif Radhitya Wardana wrote:
> > > > >    Based on this changelog, what will happen in the future to SysV? I mean,
> > > > >    if systemd forces people to create native systemd units, will people drop
> > > > >    sysv scripts on their apps?

> > > > >

> > > > >    On July 29, 2023 3:20:17 AM GMT+07:00, tito via Dng <dng@???>
> > > > >    wrote:

> > > > >
> > > > > Hi,
> > > > > A new, official systemd release (254) has just been tagged:
> > > > >

> > > > >   * Support for System V service scripts is now deprecated and will be
> > > > >     removed in a future release. Please make sure to update your software
> > > > >     *now* to include a native systemd unit file instead of a legacy
> > > > >     System V script to retain compatibility with future systemd releases.

> > > > >
> > > > > A wonderful excuse to remove the last init scripts from packages.
> > > >
> > > > Do I have to resurrect my ancient LSB compliant SysV init code that could
> > > > figure out dependencies, run things in parallel, and even work with init
> > > > "scripts" written in ANY language? It was written as a busybox module,
> > > > and could even cope with multiple other init "scripts" as modules in the
> > > > same busybox binary. LSB compliance means it reads the headers, which in
> > > > typical init scripts are shell comments in the first few lines of the
> > > > script.
> > > >
> > > > I could teach it how to grok shitsemDie units.
> > > >
> > >
> > > Hi,
> > > yes using the info contained in .service units would be
> > > a elegant solution, but they ship a lot of them (and timers,
> > > targets, etc) so I suspect that picking the right ones
> > > is not simple without hardcoding the names (not so elegant),
> > > also the command lines used are different as the ones
> > > in SysV init scripts (daemonizing, logging).
> >
> > If I ever go ahead with this, I'll figure it out. I'm great at that.
> > B-)
>
> Hi,
> I think this is the only way to stay ahead of systemd devs
> using their own momentum. Init scripts are the preferred
> tool to marginalize other init systems as you have to ship
> them yourself for every daemon out there, using service
> files to get the info and rebuild init scripts on the fly
> at first boot would be such a masterpiece!
> If you need any help (testing or whatever) drop a mail.
>
> > > I would like to see your busybox module as I love busybox
> > > code. I recall that something like what you propose maybe
> > > was attempted (as a GSOC?).
> >
> > Since you asked, I moved it from SourceForge to my own server (like I had
> > before with my github projects), and converted it to git from cvs.
> >
> > https://sledjhamr.org/cgit/urunlevel/
>
> Cloned.
>
> If I understand it right it uses C instead of scripts for LSB
> stuff and functions?

As I mentioned before, it can handle init "scripts" written in ANY
language, including C and bash. Some example init "scripts" also written
to be part of busybox are included. Being Busybox modules, they are all
written in C. Also included are the various other commands that go along
with Sys V init per LSB. So it works fine with all the scripts you
already have in /etc/init.d/.

urunlevel/runlevel/boot_portmap.c for example, the "init_d_handle_t
my_commands" structure includes all the LSB header info that you would
normally see at the top of a typical Sys V init script.

> > Haven't touched it in 18 years. lol
> >
> Ciao,
> Tito
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.