Re: Dropping SysV init script support? (was: systemd prerelease 254-rc3)

[Neal Gompa <ngompa13@xxxxxxxxx>]

On Mon, Jul 24, 2023 at 11:40 AM Luca Boccassi <luca.boccassi@xxxxxxxxx> wrote:
>
> On Mon, 24 Jul 2023 at 16:30, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
> >
> > On Mon, Jul 24, 2023 at 9:00 AM systemd tag bot
> > <donotreply-systemd-tag@xxxxxxxxxx> wrote:
> > >
> > >         * 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.
> > >
> >
> > What's driving this change? Already distributions have to manage the
> > code that integrates the sysv init script support into systemd (such
> > as chkconfig(8) and debian's systemd-sysv-install for update-rc.d(8)).
> >
> > To the best of my knowledge, the sysv support code actually *in*
> > systemd is mostly around the systemd-sysv-generator that creates
> > transient units to express dependencies. There's also the small bits
> > in systemctl(1) itself for triggering the generation of those units.
> >
> > Is this something that could be externalized into a separate project
> > and framework like systemd-initctl was? Perhaps it could even be a
> > pattern for others to implement translation for their own things to
> > systemd (e.g. runit, et al).
>
> Why not just add a unit where it's missing? It's been a decade or so,
> most things should be in place now

Because I don't necessarily control what other people do. And there's
still a very long tail of software out there that only ships a
sysvinit script. There are still people upgrading from RHEL 5/6, SLE
11, or Ubuntu 14.04 too. The software they bring along that they can't
change would still be using sysvinit scripts.


-- 
真実はいつも一つ！/ Always, there's only one truth!