From owner-freebsd-current Mon Jul 21 02:58:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA03854 for current-outgoing; Mon, 21 Jul 1997 02:58:42 -0700 (PDT) Received: from minor.stranger.com (stranger.vip.best.com [204.156.129.250]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id CAA03847 for ; Mon, 21 Jul 1997 02:58:38 -0700 (PDT) Received: from dog.farm.org (dog.farm.org [207.111.140.47]) by minor.stranger.com (8.6.12/8.6.12) with ESMTP id CAA14939; Mon, 21 Jul 1997 02:59:10 -0700 Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id DAA13113; Mon, 21 Jul 1997 03:01:33 -0700 (PDT) Date: Mon, 21 Jul 1997 03:01:33 -0700 (PDT) From: Dmitry Kohmanyuk Message-Id: <199707211001.DAA13113@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. Newsgroups: cs-monolit.gated.lists.freebsd.current Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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.