Bugs for Sorcery are reported here

[bugzilla-daemon AT metalab.unc.edu]

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.