Re: thoughts on rudimentary dependency handling

From: Luke Diamand <luke_at_diamand.org>
Date: Thu, 08 Jan 2015 23:08:27 +0000

On 08/01/15 17:53, Avery Payne wrote:
> 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.

Why shouldn't they be mixed in? Surely better to see everything clearly
and plainly, than to hide some parts away where people won't expect to
find them. I think this may confuse people, especially if they use tools
that ignore hidden directories.

At least on my Debian system, there are hardly any other hidden files or
directories of note under /etc, so this would be setting a bit of a
precedent to have quite so many non-trivial items present.

> 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.

Move everything down one level then?

sv
    - templates
    - run-scripts
    - other-things-not-yet-thought-of

FWIW, I started trying to make a debian package, and dpkg got very upset
about all those dot files.

>
> 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 - 23:08:27 UTC