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

Re: question database...



On Sat, 3 Jan 1998, Eduardo Diaz TSC wrote:

> Hi!
> 
> > 	But what about postinst that ask questions conditionally?
> >  (look at a kernel-image postinst for an example).  Some of the
> >  questions asked depend on testing the state of the machine.
> 
> Well... For some questions like those on mime applications order, 
> the admin could determine a default policy... For some others, 
> questions cannot be avoided :-( 
> 
> > 	I guess I am trying to point out that questions can't be
> >  totally removed from postinst scripts without (significant) loss of
> >  functionality.
> Some questions can have an automatic answer... some others not.
> We sould make life easier for the admins, shouldn't we?

The point that's continually missed in these discussions is
that these issues have already been successfully addressed
by others.  If they can do it, then so can we, unless we're
really that inferior.  SVR4 packages have different
classifications of "scripts" in the package layout, one of
which is "request", where all of the interactive prompting
is done in isolation of anything else that gets done.  With
this scheme, its easy to identify what needs dealing with
for each package, and easy to provide answers to questions,
default values, etc.  There are other aproaches as well.

Instead of getting into that same negative groove of "but
its more complicated then that" and using this as an excuse
not to move forward, we should rethink the parts that are
making it too complex and simplify things.  There's no
reason why all interactive coding shouldn't be in a separate
script, where its easy to identify and manage.  There's no
reason that a sysadmin couldn't answer all questions up
front using a tool like pkgask that stored per package
answer files to be used at install time.  This is just one
simple way to deal with "complicated" prompting.  We need
people to direct their energy towards solutions instead of
just "wait for COAS".  We could just as easily "wait for NT 5"
and have as much practical control (even with source code).

Its true that preparing to do real auto-installation, and
program driven configuration is non-trivial.  But so is
integrating free software into a serious operating system.
There are some decisions that need to be made about how to
move forward that need to come from the top down.  That's
the only way we'll stop "discussing" the downside to every
idea and start finding ways to overcome the various
obstacles that currently stand in our way.  Is Bruce or Ian
willing to at least get involved enough to say one way or
another if alternatives to COAS will even be considered?

Thanks

-- 

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