user questioning

Steven Michalske hardkrash at lunar-linux.org
Sun Oct 5 16:09:24 GMT 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

an idea the elaine and i were thinking about was to have specified levels of 
questioning.

level 0 = no questions default (full) all around install
level 1 = no questions minimal install
level 2 = some questions
level ...
level 10 = full local sa config type of install

numbers to change bitfields were thought of e.g. 0 1 2 4 8 16

this is not ment to tromp on your ideas nestu

hardkrash

On Sunday 05 October 2003 4:01 pm, nestu wrote:
ne> Hi, everyone ;)
ne> I have had some [very late, very short and very sleepy]
ne> thought about user questioning (ok, maybe you dislike it at
ne> all, but consider it a little brainstorm...):
ne>
ne> * I dunno if a unique file with default module wide options
ne> has been ageed , but why not have it?
ne>
ne> * IAC, one or many files, we could keep it cleanly separated
ne> in 2 parts:
ne> ¬ Default options, maybe with a subset "necessary" (
ne> necessary =  do *never* change ) options. Maybe necessary
ne> options 	should not even be available to be changed (upon
ne> second unbuffered thought...)
ne> ¬ Extended options ( commented out, and uncommenting enables
ne> them ?).
ne>
ne> * Make a small "elin" dialog script to change options before
ne> actually linning, that would update the option file(s).
ne> ¬ If finally the options are kept in various files, the user
ne> wouldn't have to search, and would know inmediately what
ne> options (s)he'd have available and could change (w/o knowing
ne> the internals, and thus less probabilities of breaking
ne> things). This would not interfere in a normal lin, AFAICS.
ne> ¬ The option files would have to keep a readable format.
ne>
ne> * Does a change in a linned module A (added an option to the
ne> default) have to propagate to the linned as depedencies
ne> module B? Say for example you set a $Prefix (a hand made
ne> change) in  A. When parsed the options file(s) from the
ne> dependency module B, check if the variable is set (in this
ne> case $Prefix), and if so use it; if not, just use the the
ne> default $Prefix in B's option file(s).  My point is that (in
ne> this example) the $Prefix could go in to a option file.
ne> Maybe this is the case of  'profile' modules, and it could
ne> be a way of setting profile modules wide settings. (Maybe
ne> I'm *really* late on this, and errrr... this is sounding a
ne> little OT :\ ).
ne>
ne> * Dunno if I talk too much, say too little, and what I ask
ne> for is impossible :\ ( no comments to this point, please :þ )
ne>
ne> If this is half understandable, that means I'm nearly there
ne> :þ Thanks for the patience! ;)
ne> CU,
ne> nestu ;)))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/gHp8JhwOdxS4dYERAhBFAKCLSaccVVFdE9nMB87GQYI9LO5/ZgCfZqvj
U8/8YkFQe2kTQviXlZzLqsQ=
=wt/m
-----END PGP SIGNATURE-----



More information about the lunar-dev mailing list