Date: Mon, 21 Jul 1997 03:01:33 -0700 (PDT) From: Dmitry Kohmanyuk <dk@dog.farm.org> To: asami@cs.berkeley.edu (Satoshi Asami) Cc: freebsd-current@freebsd.org Subject: Re: Heads up and and a call for a show of hands. Message-ID: <199707211001.DAA13113@dog.farm.org>
next in thread | raw e-mail | index | archive | help
In article <199707121201.FAA07881@silvia.HIP.Berkeley.EDU> you wrote:
> * Well, it's a nice field, yes. Editable I'm not so sure about. :-)
> * We need some way of doing this from scripts and other utilities,
> * and I guess that's the next step.
> I thought the whole point of enforcing a strict syntax to rc.conf (one
> variable per line, comments in the same line after the `var="value"'
> pair, etc.) was to make it easily editable from scripts.
> At least it's not much less auto-editable than the proposed
> /etc/ld.so.config, considering that they need to delete lines when the
> user deinstalls the package....
> One can even argue that it is just as easy because if they want to be
> really lazy (i.e., don't even want to use ed/sed/awk), they can just
> do something like
> echo "local_startup="${local_startup} /usr/dt/lib # CDE, do not touch" \
> >> /etc/rc.conf
> during installation and
> mv /etc/rc.conf /etc/rc.conf.tmp
> grep -v '^local_startup=${local_startup} /usr/dt/lib # CDE, do not touch$' \
> /etc/rc.conf.tmp > /etc/rc.conf
> rm /etc/rc.conf.tmp
> for deinstallation.
[ this is a long message - sorry ]
and they should do it this way - otherwise (if they patch local_startup)
if then some other package patches local_startup also, how they would
uninstall?
I see this (rc.conf, ld.so.conf, /usr/local/etc/rc.d/*) as one big
issue:
how do we handle a `configuration as a associative (keyed) array'
(ordered - rc.d/ or unordered - rc.conf) as a transation-capable
storage (i.e. with atomic `add' and `remove' operations?)
Jordan, you should remember that package talk we had on FreeBSD SFUG
meeting before last one - I said that the only transaction primitive
supported by filesystem is `add file' and `remove file'.
Here, we have a config variable (list of shared library paths) with
following operations supported:
- add a path to a list
- remove a path from a list
- generate list of all paths in use
we also have historical behaviour of /etc/rc just figuring list of
paths as those which exist among the supported ones (/usr/lib,
/usr/local/lib, /usr/X11R6/lib)
we also have a need for an application package to install many changes
in different config variables (like startup script collection,
library path collection) and then we want to have some way to
take our changes back. Right now the supported way is to add
one file to /usr/local/etc/rc.d .
What is bad about this approach is that there is no easy way to
find out exactly what was done by that script; say, I want to remove
all libraries added by this package by its startup script. (this is
probably the reason to have `stop' scripts.)
If we agree about atomic operations on file system, we can use
a _directory_ as a value for some option (like set of library paths)
and have each package install a _file_ for its parameters in this
directory (so the list of directories is the content of all files
in this directory, concantenated.)
This way, once a package gets some unique name, this name can be
used to add some package-specific configuration to _many_ places.
Now, we know how to implement transaction properly (i.e.: package
started install itself, modifying /etc/rc.conf, /usr/local/etc/rc.d/,
/var/db/pkg/..., and then a system crash occured. How to recover?) -
there is an `active packages' directory and keys not present in
this directory are ignored when constructing option lists.
This probably is best implemented using either a smart filesystem
or with a set of simple tools to add and remove, atomically,
a key/value to several configuration directories, and to get
a concatenated list of values within given directory, sorted or unsorted.
If several packages need to have ordering, they have to have their
key names with a common prefix (like aaa.bb and aaa.cc), and sort on
suffix.
This sounds like the R word implemented properly within BSD framework. ;-)
--
To steal from one person is theft. To steal from many is taxation.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707211001.DAA13113>