On 24/09/2015 18:45, Avery Payne wrote:
This is probably the only real problem in the arrangement I'm using
then. The entire premise is "the support scripts live where the
definitions live and are called with relative pathing, allowing the
definitions to be located anywhere".
My point of view is that service directories have their place on a
RAM filesystem, so they should not include heavy data. Stuff like
support scripts is read-only: it doesn't have to be in RAM.
You can have local data with relative pathing... in your own
service directory. As soon as you exit your service directory,
it's global data.
This was done precisely to
avoid the mess of "you MUST have your scripts/support scripts live at
this exact path", which was originally inspired by a message exchange
we had months ago about separating policy from mechanism. For my
definitions to work, those four dot-directories have to live where
the run-time definitions live. In this case, your compiled directory
is the equivalent of a run-time directory.
I am certainly not adverse to changing their names or locations - the
entire purpose is to have a set of definitions that work out of the
box, and I need to make it do whatever is required to achieve that -
but I cringe at the concept that I would need to use an absolute
path, because I'll end up making everything brittle as a result. I'm
open to suggestions on how to fix this.
I'd suggest something like a BASEDIR environment variable, defaulting
to "." or "../svcdef" or whatever the relative path for your support
scripts normally is. All your calls to the support scripts would then
start with ${BASEDIR}. Is it envisionable?
The only magic needed is that the support directories have to be
located in the same runtime location, so that the relative path links
will align and everything will be found. The compiled definitions
are the equivalent of a runtime location, therefore, they must live
there.
Nope, it doesn't work that way. s6-rc relocates the service directories
at run time, and it only knows how to handle service directories. If
you have extra data, put it either in a service directory or completely
outside s6-rc's reach.
(a) stay a symlink pointing to a directory in /data, in this case the
directory is named /data/1.0.0 or (b) dereference /env entirely,
turning /env into a real directory filled with the contents of the
files in data/1.0.0 so that the files are retained. Either solution
works.
Currently, (a) happens. I don't guarantee it will stay the same, but
it should, and if it ever changes, it will change to (b). So that will
not be a problem.
It doesn't matter if they have a wrapper, as long as the terminus of
that chain ends up calling ../.run/run at some point.
Honestly, if you're interested in converting your supervision-scripts
to the s6-rc format, I think it will be easier to work on an automatic
offline converter that takes your scripts and rearranges them in a
format that plays nice with s6-rc-compile than to try and port your
whole directory structure. It's not like you're going to need all the
compatibility layers if you know your target is s6-rc, hence s6.
One of the stated goals of the project is that there will be
no such thing as a separate /run file in each definition
Can you clarify what benefit you're getting from that approach?
--
Laurent
