[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Info about dtxtdb



On Tue, Dec 16 1997 8:05 EST "Richard G. Roberto" writes:
[snip]
Thanks a lot for your detailed analysis.

> I think there was none.
This was my impression too. My last e-mail on this subject was dated
from Aug 16 from Bruce `Time for a prototype'. :(

Some things I can answer directly (most other items have to be
discussion on the list):

> 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. 

IMO it is important that the database remains in textual form and
can be edited directly with ${EDITOR:-vi}. This ensures that
the admins won't change the scripts directly and render the
database thus useless.
 
<templates>
Templates are at the moment out of discussion for dtxtdb.
dtxtdb is IMO momentarily only for storing values which would
otherwise be scattered throughout the scripts (analogous to
the /etc/default/rcS-script which is sourced by the various
scripts in /etc/init.d/*). If we have that, we can discuss
templates again :)

> 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.  
Yes, I agree.
> 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.
ditto.

Thanks again for the repsonse,
  David



--
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: