Re: Info about dtxtdb
On Mon, 15 Dec 1997, David Frey wrote:
> Sure, you're right. This is really a good idea. The next step beyond
> dtxtdb would be a set of utilities (debask for the console, a tool
> for X11, ...) which would present these messages to the user.
>
> We had a discussion some time about this. What was the consesus?
>
> David
I think there was none. We got side tracked on the config
file parser thing and then we all fizzled out. Basically, a
package's pre/post scripts should be able to check to see if
there is a source setting for configuration data (such as a
database name) and use that to get and put its settings it
would otherwise prompt the user for.
This is where we got into muddy water before. Some of us
thought that we should only automatically manage scripts
that are currently being managed as config files. Come
wanted only config files, while some wanted to manage both.
Then there were issues about metadata (information about a
varialb/value or key value pair), rollback, etc. There was
a discussion about namespace requirements, but it never
really got off the ground. These issues would still need to
be addressed (even if we decide to just ignore them for
now).
There is still the issue of people being able to use the
database themselves in case they decide to change settings
originally stored there, or a way for a pre/post script to
detect changes from the previous installation and fall back
to the current behavior (this may quickly render the
database useless though). I think this was the stickiest
issue. If the database gets used initially, and the admin
updates the configuration in the file (as we all do now),
the database would need to be informed of those changes or
become useless.
And then there's the issue about comments in the config
files ... oh yeah I remember this now. For some reason I
remember templates being the most popular compromise, but I
may be wrong. The trouble is, we really can't ignore most
of these issues or the tool breaks the second time it gets
run -- no matter how limted its use or scope -- unless the
database becomes the sole point for storing the data used in
the files being managed. We could limit its use to only
answering questions about package installation that don't
wind up as definitions is a config file somewhere, but I
don't know of any. Oh well.
I'm glad someone is interested in getting something going
again. The prospect of waiting for Caldera to produce a
commercial product (with dependencies on another commercial
product, and a scripting language we've not yet adopted as
standard) doesn't thrill me. I think we need control over
any tool we're considering as a major part of our OS. We
could more easily provide various levels of compatability
with the COAS tool once its available than to port (and
maintain ports of) its non-free or otherwise undesireable
elements.
Just my 2.54 yen.
--
"Until we extend the circle of our compassion to all living
things, we will not ourselves find peace" -Albert Schweitzer
Richard G. Roberto
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-admintool-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: