Lynn Avants wrote:
My line of thought to modifying the existing packages would be
to add two text files: 1) A file that includes all variable names used
with the package _except_ base variables that should already exist (ip addresses and the like) 2) A file that listed depedancies
for the package (libm, libz, ifconfig, etc...). In the conf files themselves
all variables should be inserted where necessary and the
global db file should be sourced. This stays along the lines of our
current packaging w/little modification and also stays in-line with
.deb, .udeb, and .ipkg formates (the latter are reduced .deb formats).
Roger that. So I think the concept you describe above is taking form as one viable option for a global config-db. Maybe we'll call it the flat-db idea.
I would consider doing something like the PacketFilter 'mpg.lrp" package
where saved conf files (or sic the global variable file) are saved. If loaded
last, it overwrites the other packages conf files (or default values when appended to the global file) on re-boot. Food for thought anyway.
I'd rather not see the package confs require overwriting. Once they are sanitized and packaged into a .leaf package, they shouldn't need altering. Additional variables like eth4 should be addable to the config-db, which triggers all packages dependant on that sort of thing to restart. Isn't that a good idea?
Why a type? All the variables need is a value (and/or list of
available values). These can be passed by hand-editing,
script-file, menu, http/cgi, Java/Jscript and the use of 'sed'.
I agree at this point until convinced of the glory of a more complex db.
Matt, you are more experienced with Oxygen than I am. Exactly how does David deal with this with his optional menu system? Use of 'apkg' itself isn't too crazy of a thought.
David created apkg to be an extension of the current packaging system in that any additional functionality was merely brute force shell scripting. He created no special global file. Apkg can only backup files to the primary floppy w/o rewriting the code. David also spent a fair amount of time creating a terminal based gui as a replacement for lrcfg. It was the same interface as lrcfg, as far as options and how your are dumped to vi to edit the chosen file. He called it acfg. So he made acfg to replace lrcfg. And he made apkg to replace lrpkg. A little confusing, at first, but that's how it always is. It must have been at least 6 months before I even realized that lrp-2.9.4 even had an lrpkg. Apkg can remotely load packages over ftp, http, tftp, ssh... The final addition he made was that acfg was built in such a way that it could appear exactly the same on on your LEAF terminal as it would remotely in X. He made it so it would appear as an X GUI app. So in a sense he did everything people are asking about, except two things: He never built a central config-db, and he never built acfg so that you change values in the GUI; you change values in vi. Both of his apps have fixmes at this point. Best, Matt. ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
