Hello,
El sáb., 27 oct. 2018 a las 16:12, Steve Litt escribió:
>
> So I've created the following terminology:
>
> du: Daemons used. Refers to the symlink directory or its
> subdirectories. /service in the original daemontools is an example
> of a du directory. /etc/sv in both Void Linux and Debian and Devuan
> is an example. In Devuan I'd make this directory /etc/du/runit.
> There could later be an /etc/du/s6 or /etc/du/daemontools.
This one already has a name: scan directory (the pathname argument
runsvdir is invoked with). However, I believe that this is
/run/runit/runsvdir/current on Void, and /etc/service on Debian, not
/etc/sv. In the first case, that's a symbolic link to
/etc/runit/runsvdir/current so that one can use runsvchdir(8):
*
http://www.smarden.org/runit/runlevels.html
In the second case, that's a symbolic link to
/etc/runit/runsvdir/default apparently?
If so, your proposed location would differ from that of Debian
stretch's and buster's runit package, and therefore currently Devuan
ASCII's and Beowulf's, right? Wouldn't Devuan have to fork the package
to change the convention then?
*
https://packages.debian.org/stretch/amd64/runit/filelist
*
https://packages.debian.org/buster/amd64/runit/filelist
> da: Daemons available. Refers to the directory housing the real-file
> directories that are symlinked in the du directory. Material in the
> da galaxie is site-modifiable to accommodate site specific needs.
> In Devuan I'd make this directory /etc/da/runit. There could later
> be an /etc/da/s6 or /etc/da/daemontools.
>
> dp: Daemons packaged. Refers to a directory housing unmodified
> material straight from the runit_daemons package. The dp directory
> shall consist of a directory holding daemon directories for every
> daemon in the collection. The daemon directories shall not contain
> any supervise file, directory or symlink, nor any log files or
> directories meant to hold log files, nor any other stateful
> things. The intent of the dp directory is that its material is
> modified ONLY by later packages, never on-site. It's therefore
> entirely read-only. In Devuan I'd make this directory /etc/dp/runit.
> There could later be an /etc/dp/s6 or /etc/dp/daemontools.
I usually call these 'service directory repositories', and I believe
on both Void and Debian that is a single directory, /etc/sv, managed
by the package manager, just like /etc/init.d. Again, wouln't changing
the convention set up by Debian packages require a fork?
*
https://packages.debian.org/stretch/all/getty-run/filelist
*
https://packages.debian.org/buster/all/getty-run/filelist
> runit_tool -i daemonname sees whether the dp version of the daemon dir
> matches the da version, and if so, does nothing. If different or da
> version is missing, it first backs up the existing dp version then
> overwrites it. If the now backed-up dp version matches the da version,
> the da version is assumed not to be custom, and the new dp version
> overwrites the da version. If the backed-up dp and the da differ, it
> assumes the da version is customized, and via backups and warnings,
> walks the user through his/her choices.
>
> runit_tool -e daemonname creates a symlink of the da in du. If nothing
> to symlink to, issues a warning.
>
> runit_tool -d packagename removes that symlink. If no symlink,
> issues a warning.
>
> runit_tool -u daemonname issues a warning and refuses to act if
> there's currently a du->da symlink. If the da version of the daemon
> doesn't match the dp version, issues a warning about it being
> customized, and makes the user strenuously opt in to deleting the
> daemon directory from da. Does not affect dp at all.
Doesn't this overlap functionality (in a contradictory way) with
update-service(8) (a Debian addition to runit)?
*
https://salsa.debian.org/runit-team/runit/raw/master/debian/contrib/update-service
G.
Received on Sun Oct 28 2018 - 18:33:45 UTC