This is so cool!! This is all just what I've been wanting. Great suggestions!!
I think the class inheritance mechanism provided by a class spec/config/whatever file is nice: ---------------- Class: GNOME # Other classes to recursively define Depends: XF86 Depends: WORK As to whether to throw the packages in there too? I think not soley because that would require more extensive updates to existing FAI installations. Adding a spec file to define inheritance alone allows the existing package file mechanism to work with the existing config files. This brings up a side issue. While I'm all for improving something, don't break the existing config mechanism simply for the sake of it. The easier admins can upgrade to the the new FAI, the more that will. Or, at least phase the config file restructuring in order to keep as large a user base as possible. One thing that may be nice, is to leave the config filenames the same, if possible, and leave the deleted code present but commented out, to ease the task of diffing the new config files with our own. I don't think that this spec file should make any reference to the scripts/hooks/etc that are defined by the class. This just makes it harder to add stuff to a class because you need to update the class spec file too. One thing I'd like to see addressed it the order that the script directory is processed. Currently the scripts are run in the order the classes are defined. How about a scripts/XX.CLASSNAME.source filename format so you could use the XX as a number to control the execution order? -Bruce > -----Original Message----- > From: Niall Young [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 22, 2002 12:58 AM > To: AUSTIN MURPHY > Cc: linux-fai > Subject: Re: Future of FAI (fwd) > > > On Fri, 22 Nov 2002, AUSTIN MURPHY wrote: > > > 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. > > > > > > 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 > > > > 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 > > > > Your directory concept solves #2 very well. I don't think > it addresses #3 > > and or #1. > > I don't see #3 being a real problem now, and #1 not being > implemented yet > means we're not yet restricted - it can be built either way. I'm not > suggesting any real change in how they work, only where > they're located on > disk. Combining the .var and anything else relevent into the > spec file sounds > great, but I don't think you need everything in there. A bit > of both sounds > like the best solution, a uDeb or tarball down the road and > then people can > more easily trade classes and improve them. > > Niall Young Chime > Communications Pty Ltd > [EMAIL PROTECTED] Level 6, 263 > Adelaide Terrace > Ph: 08 9213 1330 / 0408 192 797 Perth, Western > Australia 6000 > > "there's a lot of movement in my trousers at the moment" > -- Dennis Kristofich, Sep 2002 > >
