Re: dcfgtool and clones
Well, I promised myself I wasn't going to get involved in this
kind of thing, but I'm about to get a private internet connection
so I should be able to insulate my job from these discussions
soon. I would like to make the following requests of those
working on this project:
Please do not create a proprietary configuration interface.
Any admintool should not require people to use it. In other
words, if an admintool uses a textdb tool, they should be used to
create "standard" config files that anyone can administer
themselves (without these tools) and possibly distribute to
non-debian systems. If I have a UUCP config for Taylor UUCP
version X on my debian box, my config files should plug and play
on any properly installed Taylor UUCP version X. The same goes
for X11, xdm, TeX, lpr, etc.
Package maintainers could make use of the textdb tool to
"register" config values shipped with their package, or retrieve
values stored from a previous installation, but not to replace
upstream config/setup/startup files that would not have otherwise
been replaced by debian.
The tool(s) should not enforce policy, but rather be generally
useful to be able to conform to policies. Discussing how we
should change the debian policy because we want to make a tool
that acts a certian way is a bad idea. Develop the tool. Let it
be used to implement current policy. If and when policy changes,
the tool should not need to be rewritten to implement new policy.
Basically, please leave the policy discussion out of the
developement discussion. Users may not like debian policy and
may have their own. They should be able to use the tool to
implement a site/company specific policy (which may be a
replacement for, subset of, or superset of debian policy) for any
given package. The web policy is prime candidate for this sort
of thing.
One more request: please don't over-simplify the _usage_ of the
tool. A very simple tool could be used to do very sophisticated
things. Storing state information about configurable data and
global/package-level behavior flags regarding
upgrades/installations, etc. are all possible with cfgtool if its
used by a wrapper that just calls cfgtool to put/get/modify data.
The virtual structure of the data does not need to be limited to
its physical structure.
I'm only subscribed to debian-admintool at the moment, so please
keep the discussion at least CC'd there.
Thanks
Richard G. Roberto
richr@bear.com
011-81-3-3437-7967 - Tokyo, Japan
--
*******************************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, offer or
agreement or any information about any transaction, customer account or account
activity contained in this communication.
*******************************************************************************
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: