Re: Proposal: Automatic query servicing for dpkg installation scripts
On Tue, 19 May 1998, Oliver Elphick wrote:
> Well, having looked at COAS, it seems not to dictate any particular data
> format; it has to cope with a large number of independently developed
> packages, each with its own format. To add a new one means writing a
> module which plugs into COAS to handle the new package. Once COAS is
> available, this can easily be done.
Specificaly the information I was talking about is the schema sub
directory. It is not quite what I was expecting (last I looked at coas it
was not for this detail) and I'm really not terribly enthused about it.
What I was thinking (and what some of the COAS docs claimed) was that it
was much like the SNMP MIB descriptions. Let me elaborate..
For each possible question we would describe the form that the answer can
take and we would describe what we are asking. SNMP uses ASN.1 notation
and looks something like
sysORIndex OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used for identifying instances of
the columnar objects in the sysORTable."
::= { sysOREntry 1 }
COAS provides the SYNTAX information but completely ingores the
description - your format completely ingores syntax. What we need is
description, syntax, defaults and so on as we scale up to more interactive
systems
Maybe like
mailname OBJECT-TYPE
SYNTAX STRING
STATUS mandatory
DEFAULT "debian.org"
DESCRIPTION
"The externaly visable mail name of the system"
::= { .. }
I don't know if we want to use ASN.1 - It seems like a nice idea to use
existing defined things however. We could probably even use the same form
as the Package files, or we could use SGML, or something totally new - it
really doesn't matter, any thing I say about ASN.1 can be applied just as
well if it is in some other form.
Like the way SNMP works the ASN.1 description would serve only as the
information that the UI tools use to understand what they are viewing.
The actual answers to the questions could be stored in some arbitary
database - this is something the packager does not have to deal with.
As we get more fancy we can extend the description to encompass a wider
range of database options [say native config files for the package] and to
encompass actual management.
So, to the package writer the tasks required of them would be to write a
Description of the configuration questions and then in their script
instead of prompting they would call a query program which would prompt
depending on various conditions.
Now, how this solves Ian's points,
#1 - I read this as meaning the questions are seperable - they would
be present in the Description file (MIB in SNMP notation) We could
make them avail for download via http just like changelogs are now.
#2 - The package has control here, it's script is performing the queries
into the database. As we scale up to pre-configuration the package
can optionally provide a UI Plugin that provides it's logic functions
If it does not then the user will simply have more things to answer
than is stricly relevent to their choices.
#3 - If we follow the SNMP model then each quesiton has BOTH a name and
a numeric string arranged in a heigharchy (debian.mail.mailname for
instance)
#4 - This is just a field in the 'MIB'
#5 - It is, because each question has a structured form we can have a
generic GUI that can browse the question tree. With options to
install 'Plugins' in the GUI we can scale even more so.
#6 - Implementation detail
#7 - ??
#8 - Implementation detail (related to #4)
#9 - This is handled more generally by typing the responses in ASN.1 -
this is MUCH more suited to a generic GUI than a regexp, but it does
not exclude the possibility of a regexp type.
#10 - This is not covered in the SNMP model. I suggest a a substition
system in the description feild that allows lookup and substition
of other database entries and to a lesser extent environment
variables (env vars limit the usefullness of a GUI tool)
Perhaps $(debian.mail.mailname) and #($FOO) ?
There are also a few other interesting benifits
#0 - We are -VERY- similar to something estabilished, we don't create
new languages or even so much new concepts
#1 - SNMP presents itself as good choice for a remote
administration protocol
#2 - We provide a native configuation storage system for apps/scripts that
desire. This is instead of the usual technique we have been using of
having a script as a conffile or having the script source another
file.
#3 - Using a heigharchical structure gives each package alot of freedom
in what variables they can have
#4 - The package writer does not have to use the query program to generate
the prompts, they can come from within the script, an external
program, a GUI plugin, etc - there is alot of flexability in how the
information can be inserted into the database and how it can be taken
out of the database - this is nescessary as we move to a more plugin
rich environment (imagine how ecompassing a sendmail plugin could be)
Some things we should look at,
- Free ASN.1 parsers/libraries, I think one is around
- What fields can be borrowed from SNMP and what more do we need?
- Consider how we would model some of the existing setup scripts
in ASN.1 and verifiy that this -IS- an acceptable model.
[Anyone want to do these? I should be working on APT.]
dtxtdb is not at all the same solution as this - it models the backend
native database/cache, which does not deal with any of these issues.
As a final thought, it is my belief that implementing a 'simple' system
like Oliver started with would be suicide. We would lock ourselves into
something that is not extensible or realizable into a powerfull GUI.
Jason
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: