On Fri, 22 Nov 2002, Niall Young wrote:
> On Fri, 22 Nov 2002, AUSTIN MURPHY wrote: > > > I was thinking of a single "spec" file to define each class with an > > associated tarball containing all related scripts and files. > > > # scripts (location) > > /fai/scripts/GNOME/S01 > > /fai/scripts/GNOME/S03 > > Sounds great, but do we need a separate spec file? I like the ease > of customising classes simply by dropping SXX scripts etc. in place and > have them automatically detected instead of hardcoding them in, this > keeps it flexible and modular. I'd just separate everything from > /usr/local/share/fai/* into /usr/local/share/fai/CLASS/* with each file named > appropriately: disk_config package_config/ scripts/ etc. It's then an > isolated tree, and you could add tarball support later by just detecting > CLASS/ or CLASS.tar.gz You make a good point about dropping-in scripts etc. The idea of having separate disk_config/, package_config/, scripts/ etc. directories solves the problem of not knowing exactly what class has which sub-sections but it adds a whole lot more sub-directories than the already large number that currently exist. This is especially true under the fai/files/ directory. The key ideas behind my spec file were to: 1) allow easy recursive dependencies 2) easily see what a class does 3) reduce the number of files and directories As to #1. This doesn't exist now, but seems easy enough to implement. Once implemented I think this will simplify the initial class definition scripts. As to #3. Most of my classes have an associated CLASS.var file as well as a CLASS file for packages. My goal was to combine these 2 into a single class spec file that also included the list of scripts, hooks, and files associated with the class to solve #2. Your directory concept solves #2 very well. I don't think it addresses #3 and or #1. I don't propose to change the way FAI executes scripts or hooks nor do I want to change the behavior of fcopy/ftar. If a script was added and the spec file was not changed, I think it FAI should run as it is expected to run now (with the new script, regardless of what the spec file says). I am thinking along the lines of a Linux package manager. A package is installed with all it's dependencies met and then you can do anything to the files once they are installed. It might even be possible/practical to convert each class-pkg into a uDeb or something. (Just an idea) I'm afraid that changing the directory structure would lead to a considerable amount of work in reorienting each part of FAI that "knows" the current structure. Does this make sense, or am I way offbase? Austin Murphy ---- Systems Programmer Rutgers University
