Antony Stone said on Thu, 4 Jan 2024 19:44:28 +0100

>On Thursday 04 January 2024 at 19:34:05, Steve Litt wrote:
>
>> tito via Dng said on Sun, 31 Dec 2023 00:42:28 +0100
>>
>> > Doesn't this break the concept of package management?
>>
>> Yes. Yes yes yes yes YES!
>
>So, that IS bad news (see below).
>
>> Packages are nice for some things, and not for others. For instance,
>> the Debian package for VimOutliner sucked and the first
>> troubleshooting move we made on somebody saying it didn't work was
>> to have them download the tarball and take about five easy steps.
>
>Splendid example, but isolated. In general (in my opinion, both as a
>personal user of Devuan, and as an engineer working with several
>companies using Debian and/or Devuan) the DEB package management
>system works very well (and better than RPM, since you can upgrade
>between releases). People rely on it.

OK, it can be done with package management, if that's what's needed.

* One package contains ALL the run script, finish scripts, and any
other shellscripts needed to start each daemon in runit. These
scripts are installed, with their directories, in /etc/svall. And for
those about to say "but the disk space", these are all tiny files,
such that if you have 3000 different daemons' runit directories, this
would be 9000 inodes and a little more or less than a megabyte of
space.

* Each to each daemon's package installation/deinstallation scripts are
  added:
    - On installation, a shellscript to cp -Rp the directory to /etc/sv
    - On install, a shellsript to ln -s /etc/sv/pkgename
  /var/service/pkgname
    - On removal, a shellscript to rm -rf /etc/sv/packagename
  Because each of these three shellscripts take the daemon's name as an
  argument, these three can handle all daemons.

I'm sure people will come up with tens of creative reasons why the
preceding is unacceptable, using various hypothetical populations who
just can't deal with it for some reason. But here's the thing: There
has been a lot of "Devuan can't survive Debian's sabotage" talk on this
list. If the death of the poster-child for init choice goes under,
that's a horrible thing. And who knows: Daemon authors and maintainers
just might start to really like the preceding solution.

And as Didier said in another post on this topic, this exact same
solution can be used for sysvinit init scripts and s6 run
directories, and for that matter probably for OpenRC. And most likely
for Epoch and Busybox init too.

SteveT

Steve Litt

Autumn 2023 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21