Re: thoughts on rudimentary dependency handling

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Thu, 8 Jan 2015 09:53:09 -0800

The use of hidden directories was done for administrative and aesthetic
reasons. The rationale was that the various templates and scripts and
utilities shouldn't be mixed in while looking at a display of the various
definitions. The other rationale was that the entire set of definitions
could be moved or copied using a single directory, although it doesn't work
that way in practice, because a separate cp is needed to move the
dot-directories.

The basic directory structure is as follows:

sv
-> .bin
-> .env
-> .finish
-> .log
-> .run

Where:

sv is the container of all definitions and utilities. Best-case, the
entire structure, including dot directories, could be set in place with mv,
although this is something that a package maintainer would be likely to
do. People initially switching over will probably want to use cp while the
project develops. That way, you can pull new definitions and bugfixes with
git or mercurial, and copy them into place. Or you could download it as a
tarball off of the website(s) and simply expand-in-place. So there's a few
different ways to get this done.

.bin is meant to store any supporting programs. At the moment this is a
bit of a misnomer because it really only stores the framework shunts and
the supporting scripts for switching those shunts. It may have actual
binaries in the future, such as usersv, or other independent utilities.
When you run use-* to switch frameworks, it changes a set of symlinks to
point to what should be the tools of your installed framework; this makes
it "portable" between all frameworks, a key feature.

.env is an environmental variable directory meant to be loaded with the
envdir tool. It represents system-wide settings, like PATH, and some of
the settings that are global to all of the definitions. It is used within
the templates.

.finish will hold ./finish scripts. Right now, it's pretty much a stub.
Eventually it will hold a basic finish script that alerts the administrator
to issues with definitions not launching, as well as handling other
non-standard terminations.

.log will hold ./log scripts. It currently has a single symlink, ./run,
that points to whatever logging system is the default. At the moment it's
svlogd only because I haven't finished logging for s6 and daemontools.
Eventually .log/run will be a symlink to whatever loggin arrangement you
need. In this fashion, the entire set of scripts can be switched by simply
switching the one symlink.

.run will hold the ./run scripts. It has a few different ones in them, but
the main one at this time is run-envdir, which loads daemon specific
settings from the definition's env directory and uses them to launch the
daemon. Others include an optional feature for user-defined services, and
basic support for one of three getty. I may or may not make a new one for
the optional dependency feature; I'm going to see if it can be standardized
within run-envdir first.

I can always remove the dots, but then you would have these mixed in with
all of the definitions, and I think it will add to the confusion more than
having them hidden. As it stands, the only time you need to mess with the
dot directories is (a) when setting them up for the first time, or (b) when
you are switching your logging around. Otherwise there's really no need to
be in them, and when you use "ls /etc/sv" to see what is available, they
stay out of your way.

If there is a better arrangement that keeps everything in one base
directory for easy management but eliminates the dots, I'll listen.
Although I think this arrangement actually makes a bit more sense, and the
install instructions are careful to include the dots, so you only need to
mess around with them at install time.

On Thu, Jan 8, 2015 at 8:20 AM, Luke Diamand <luke_at_diamand.org> wrote:

> Is it possible to avoid using hidden files (.env) as it makes it quite a
> lot harder for people who don't know what's going on to, um, work out
> what's going on.
>
> Thanks!
> Luke
>
>
Received on Thu Jan 08 2015 - 17:53:09 UTC