Skip to Content.
Sympa Menu

sm-sorcery-bugs - [Sm-Sorcery-Bugs] [Bug 342] need way to set/read/remove system level configuration variables

sm-sorcery-bugs AT lists.ibiblio.org

Subject: Bugs for Sorcery are reported here

List archive

Chronological Thread  
  • From: bugzilla-daemon AT metalab.unc.edu
  • To: sm-sorcery-bugs AT lists.ibiblio.org
  • Subject: [Sm-Sorcery-Bugs] [Bug 342] need way to set/read/remove system level configuration variables
  • Date: Fri, 18 Oct 2002 08:59:56 -0400

http://bugs.sourcemage.org/show_bug.cgi?id=342





------- Additional Comments From msasgl AT msa-enterprises.com 2002-10-18 08:59
-------
I know, I've been made aware of that before ;-) and I do consider this to be
a
post 1.0 enhancement. Though speaking of 1.0 can we come up with a different
name for the menu system? Skry just fits the system detection stuff too well
to
ignore 8-)

As far as coding this goes, it should just be minor modifications to bring
the
0.2.0 libbdb into line with sorcery 1.x - I'm thinking lose my liblock and
use
sorcerys, change the variable:value seperator from : to =, keeping : as the
array seperator (or use tabs?), simplify the grep / sed commands (thus
removing /proc support - but I can do specific routines for this in the
detect
stuff), use sorcery defined paths and define a few standard records for the
database.

Unless we don't do bash post 1.0, in which case it's a full rewrite ;-)

I'm thinking a two level directory structure might be the best approach.

local/hardware/display
local/hardware/drives
local/base/bootloader
local/gui/menus
local/gui/toolbar
local/compiler/gcc
sparc1/*same*
alpha3/*same*
i586-default/*same*

So we can set:

>$DBPATH=$DBBASE/${TARGET:=local}/

then use:

>retrieve cdwriter.* hardware/drives

to get something like this back:

SAMSUNG CD-R/RW SW-240B:/proc/ide/hdc:/devices/cdroms/cdrom0:cdrom:40:12
SAMSUNG CD-R/RW SW-240B:/proc/ide/hdd:/devices/cdroms/cdrom1:cdrom:40:12

or do things like:

WRITESPEED=$(lookup cdwriter1 hardware/drives 5)
REWRITESPEED=$(lookup cdwriter1 hardware/drives 6)

It's then easy to implement cast -target xyz functionality plus gives a way
to
provide far more specific default configs on spells.

Longer term it also makes things like skrying a non-SourceMage Linux system
to
setup the database and clone its setup vaguely possible. (Told you skry was
better suited for detect stuff ;-) )

The important thing to get right at this point is the actual database design
rather than worrying about what language to write the routine in. Is there a
better option than the one I've suggested or should I just do it?

To recap, records would be stored in following paths ($s are for easy
reading):

$BASE/$SYSTEMNAME/$SECTION/$RECORDNAME

though I've also considered using

$BASE/$SECTION/$SYSTEMNAME/$RECORDNAME

each has different strengths and there's not a lot to choose between them.

The records would contain:

$VARIABLE=$VALUE1[:$VALUEn..]

to store an array with : (value seperator) in its values (eg a mirror list)
we
could use:

$VARIABLE1=$VALUE1
$VARIABLE2=$VALUE2

and use $VARIABLE.* as the variable name in the retrieves. Maybe tabs would
be
better after all - might make this bit simpler.

Anyway, thoughts, suggestions or firm decisions welcomed..



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.




Archive powered by MHonArc 2.6.24.

Top of Page