Web lists-archives.com

Re: wicd-daemon-run_1.0_amd64.changes REJECTED

Lorenz <lorenzo.ru.g@xxxxxxxxx> writes:

> That will work for runit-init, but what about runit-sysv and
> runit-systemd?  Let's say I have systemd (as init), runit-systemd and a
> foo daemon installed; and 'runscripts' package ship a run script for
> foo. How can I detect if the user wants to manage foo with runit or with
> systemd?

I think a command would work for that case as well.  What I'm imagining
would look something like this:

- If runit-init is installed, it installs a trigger that runs the command
  for any change to the runit metadata directory.  That command sets up
  the users, runit configuration, and does whatever other actions are
  needed to maintain a consistent system.

- If runit-init is not installed, by default all services are run through
  the regular init system.  However, the local system administrator can
  run the command manually, specifying a specific service, and it then
  sets up that service to run via runit in a similar way and also disables
  the systemd unit or init script.

- runit-sysv and runit-systemd install a different trigger that runs the
  script with a flag that says to update all configuration that was
  previously manually enabled by the system administrator (so that you can
  update service definitions or delete ones when packages are removed),
  and ignore all the other configurations.

Note that a lot of the runit metadata can probably be derived from systemd
units for services that have unit files.  For example, if the systemd unit
runs the daemon as a different user, runit can probably use the same user,
and the systemd unit may well also run the daemon in the foreground since
systemd prefers that for the same reasons runit does.  So it's conceivable
that you could get out of shipping explicit runit data for a lot of
packages, or ship something that just notes that the unit file can be
autoconverted.  This would cut down on the maintenance burden of the
primary package maintainer a lot.

Russ Allbery (rra@xxxxxxxxxx)               <http://www.eyrie.org/~eagle/>