Re: data packages

Thomas Schwinge <[email protected]> wrote:
> At present there is no possibility for a package to have a affiliated
> data package.

Sure there is: admin/svclean has admin/svclean-conf.  But I guess it
depends on exactly what you mean by "affiliated": the metadata files
in each package's package/ subdirectory do not give any indication of
a relationship between them.  But do we need any such indication?

> It's obvious that the configuration files can not be put into
> /package/admin/runit-xxx - that would make them affiliated to version
> xxx of admin/runit.

Right.  Adding /package/admin/runit-conf-<version> (or runit-data, or
whatever) would solve that.  The -conf package would normally never
need to be upgraded, although if a new version of runit expects its
new configuration files to be of a different format than the old
version, then the admin must choose between changing the format of the
old -conf package's files, or reapplying any local customizations to
the new version of the -conf package.

> The state files also can not be put there because you may want to have
> /package mounted read only.

We can allocate *names* for the state files under /package, which is
good enough for this list. :)

> /package/admin/runit-xxx/conf/runit-data -> /package/admin/runit-data
> /package/admin/runit-yyy/conf/runit-data -> /package/admin/runit-data-old

These would be needed if runit needs to know the path to the
configuration files at *compile time* - which it probably does,
considering its job.  But most packages should take the path at run
time, so this link would usually be unnecessary.  (The dnscache binary
does need to know the path to /service/dnscache at compile time.)

> /package/admin/runit-data -> runit-data-default
> /package/admin/runit-data-default and
> /package/admin/runit-data-old are either directories or symlinks.

Configuration packages have versions just like other packages, so
tools like sp-check don't need to have special cases to handle them.
So if runit-data-default and runit-data-old exist with exactly those
names, they would be registered as separate packages.  But I don't see
any need for those names; runit-xxx/conf/runit-data can point directly
to a specific version, or to the current-version symlink, and the
current-version symlink can point directly to a particular version.

> runit would then access its configuration and state files using
> /package/admin/runit-xxx/conf/runit-date/* and when installing a new
> version package/build should just create the symlink
> /package/admin/runit-zzz/conf/runit-data -> /package/admin/runit-data.

Yep, that works when the path must be known at compile time.  If it
can be specified at run time, the configuration package might contain
a script to call the package's programs, passing the path to this
configuration package.  svclean[-conf] uses both of these techniques,
sort of.

> Packages providing services to be run via daemontools etc. could also
> have e.g. /package/web/djbdns-data/service/dnscache. This directory
> then again would get symlinked to /service.

That's one possibility.  I like to keep all my service directories in
one place, so I use a different style: runwhen includes a sample
service directory, which you can copy to /usr/local/service/, or
wherever you like to keep your service directories; then you can edit
your copy and symlink that into /service/.

I think it's ok for different packages to use different styles here;
lack of uniformity doesn't really hurt us in this case.

> A web proxy could store its cache in /package/web/proxy-data/cache -
> with /package/web/proxy-data/cache again beeing symlinked to
> /fs/std-var/package/web/proxy-data/cache.
>
> The proxy itself would not even know about the data package. It would
> just store the cached sites in
> /package/web/proxy-xxx/conf/proxy-data/cache/.

Right.  This way - or by passing the configuration path at run-time -
we can have two versions/running instances of the package
simultaneously, for testing different configurations.  I don't think
we really need to call this method a requirement, but it would be nice
to see it documented on cr.yp.to as recommended practice.


paul