On Sun, 31 Dec 2023 11:55:22 -1000
Joel Roth via Dng <dng@???> wrote:

> On Sun, Dec 31, 2023 at 02:00:42PM -0500, Steve Litt wrote:
> > altoid via Dng said on Sun, 31 Dec 2023 05:59:08 -0300
> >
> > >Hello:
> > >
> > >On 12/30/23 12:25, altoid via Dng wrote:
> > >
> > >>> Linux has tens of thousands of very capable users ...
> > >
> > >Lars Noodén via Dng wrote:
> > >
> > >> ... work flow be modified to let them in?
> > >> ... the sea change needed in how work is split up ...
> > >
> > >I don't know exactly how the maintainer work flow is designed, I
> > >expect that each maintainer or group of maintainers has their own way
> > >to get their work done, but I.may be missing something.
> > >
> > >I think that the best way (?) to get this done would be as was said
> > >earlier by tito, to leverage/use what we *already* have at hand.
> > >
> > >ie: find a way to leverage systemd .service files to convert them to
> > >initscripts.
> > >
> > >Both .service files and initscripts are, by design, standardised and
> > >by comparison to human language, very simple so it should be (?)
> > >straightforward to translate one to the other.
> > >
> > >I may be mistaken, but I really don't think Devuan will be able to
> > >count on package maintainers to keep initscripts up to date for *us*
> > >to be able to use their packages in systemd-less distributions.
> > >
> > >That task cannot be left to package maintainers basically because it
> > >will *not* get done, it has to be done at distribution maintainer
> > >level.
> > >
> > >On one hand because, maintenance wise, it is more work for them.
> > >At the most, some may leave them around for historical purposes but
> > >the scripts will not be maintained.
> > >
> > >And on the other, because systemd is *the* tool with which MS/IBM/RH
> > >has been infiltrating the Linux ecosystem.
> > >
> > >So we can only expect for things to get even murkier.
> > >eg: unreadable .service blobs anyone?
> > >
> > >Best,
> > >
> > >A.
> >
> > So what is your solution?
>
> A bunch of folks on this list earlier posted
> the results of ls /etc/init.d.
>
> A next step would be to track the appropriate debian
> git respositories for those packages. At some time
> in future, if the debian packager removes the init
> script, you revert that commit in your repo,
> and using the debian toolchain, generate your
> version of the package *with* the sysvinit script,
> and continue to track the package.
>
> Debian publishes package popularity information, which
> could also be used to help select packages to follow.
>
> Even if you just copied the sysvinit scripts out of the
> latest debian packages, you would always have the most
> recently available version. That could be a quick hack.
>
> I think the majority of important, mature packages won't
> often have changes in their init system.
>
> Wish everyone on this list--and the whole world--good health
> and happiness in the New Year.
>
>
Hi,
just to quantify how many initscripts there are in devuan daedalus
with all repositories enabled:

eb http://deb.devuan.org/merged/ daedalus main contrib non-free non-free-firmware
deb-src http://deb.devuan.org/merged/ daedalus main contrib non-free non-free-firmware
deb http://deb.devuan.org/merged/ daedalus-updates main contrib non-free non-free-firmware
deb-src http://deb.devuan.org/merged/ daedalus-updates main contrib non-free non-free-firmware
deb http://deb.devuan.org/merged/ daedalus-security main contrib non-free non-free-firmware
deb-src http://deb.devuan.org/merged/ daedalus-security main contrib non-free non-free-firmware
deb http://deb.devuan.org/merged/ daedalus-backports main contrib non-free non-free-firmware
deb-src http://deb.devuan.org/merged/ daedalus-backports main contrib non-free non-free-firmware


apt-file search /etc/init.d/ | wc -l
1202