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).
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?).
Ciao,
Tito