:: Re: [DNG] This is going to be unpop…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Steve Litt
Fecha:  
A: dng
Asunto: Re: [DNG] This is going to be unpopular, but...
Lorenz said on Fri, 5 Jan 2024 19:09:42 +0100

>Il giorno ven 5 gen 2024 alle ore 17:50 Steve Litt
><slitt@???> ha scritto:
>
>> But wait, there's more! Each service must be modified to run a
>> shellscript on install and another one on remove. But when we say
>> "each package", can't this be done programatically?
>
>I'm not sure what you mean here, please elaborate if I guess wrong:
>currently runit-services cooperate with with runit and dh-runit to
>integrate the 'foo' service with the Debian package that ships the
>'foo' binary so it is able to enable/start, disable/stop and restart
>the runit foo service when appropriate.
>there is no need for cooperation on the Debian foo package side, to
>avoid sabotage and endless discussions


Maybe what you said, but I know little about packaging systems, so let
me try to describe what I mean, using my own fanciful names for
packages. Everything here refers to runit, and the assumption is that
/etc/svall contains the proper runit directories for every daemon
Devuan has a runit directory for. /etc/sv contains daemon directories
of daemons actually installed. /var/service contains symlinks to some
of the /etc/sv directories, and is the directory that svscandir
actually operates on.

* Package allscripts creates every known runit directory, by name,
including run script, finish script, and any other script, as well as
the log directory if needed, in /etc/svall. This frees upstreams and
daemon maintainers from having to create runit facilities. Creating
these runit facilities has been a major source of developer
resistance to "supporting" multiple init systems.

* Each daemon's package is modified to call installdaemon.sh on
install, and removedaemon.sh on remove. Because this is simply a
command and three known arguments (the name of the daemon's runit
directory, the user to run as, and the group to run as), I think this
is simple enough for a program to add those two commands.

* installdaemon.sh follows, run as installdaemon.sh foo:
    cp -Rp /etc/svall/$1 /etc/sv
    chown $2 /etc/sv/$1
    chgrp $3 /etc/sv/$1
    ln -s /etc/sv/$1 /var/service/$1


* removedaemon.sh follows, run as removedaemon.sh foo:
    if test "$1" = ""; then
        exit 1  # don't delete all of /etc/sv on no arg
    fi    
    cd /var/service
    sv stop $1
    rm $1
    rm -Rf /etc/sv/$1


Doing it this way accomplishes the following:

* Transparent to the "upstreams" and package maintainers. They
don't even know the runit facilities are created for them, and unless
they have a poetteresque agenda they'll have no objection.

* Transparent to simple users. Everything seems the same to them.

* Power users can change what's in their /etc/sv in order to customize
Devuan's idea of how the daemon is run, and they can also put their
own daemons in /etc/sv.

* Gerrit Pape and Void Linux have already done most of the work for us.

* This way also facilitates using ONLY the runit service supervisor,
with sysvinit taking the PID1 and early boot (stage 1) duties.

* An almost identical technique can be used for s6.

* And like you said, no cooperation is needed from the Debian side, so
they can't sabotage, foot drag, and commit other poetterisms.

HTH,

SteveT

Steve Litt

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