fai class hierarchy brainstorming

[Henning Sprang]

On Fri, 2006-01-20 at 17:01 +0100, Michael Tautschnig wrote:
>[...]
> > (1) the classic class directory
> Do we need it in that kind of hierarchy or even more, does it make sense? Note,
> that for that kind of structuring you need to have classes defined already!

I am not exactly sure. What about the *.var files in classes? O.K. what
is now in CLASSNAME.var could then be in CLASSNAME/variables (at the
same level as scriptes, package_config etc. above.

There are other questions:
Where would otherwise things like 10-base-classes go?
But also if we keep classes at the above location, where would
50-host-classes go then, which defines multiple classes at once?
And where will the "old" class/<hostname> files go (which I use for my
handfull of all-different hosts)?

Yeah, probably we should have the CLASSNAME.variables script as above,
but then a special location for the rest of what is now the class
directory?

>[...]
> > (3) a file which defines all packages needed for
> > that class. Should we make a directory as
> > before? maybe we want some packages be only
> > installed if another class is defined? 
> > On the other hand, the proposed way we don't need to name the file
> > CLASSNAME in a directory package_config. I think a class name should
> > appear in as little locations as possible, to make class renaming easy.
> IMHO this should be a directory and the files should be named <NR>[-NAME] such
> that the tasks could read them one by one and things like Jürgen's troubles of
> installing alsa before kernel-image could be solved by putting kernel-image into
> some file with a lower number.

it's not a big difference in implementation, yes, way to influence the
installation order can be useful. Maybe both, as with the scripts
directory - So it's easy for classes with a single package, but doable
for complex classes. Or would that be too much?

>[...]
> > (8) a file with a list of classes this class depends on
> A great idea, but IMHO hard to implement - how would you deal with those
> dependencies, what would they mean to FAI? We'd need to take care of recursive
> dependencies!

After the first, script and host based class definition process, each
matching dependencies file of a class could be checked for additionally
needed classes.
We could either track dependency paths and check for cycles, or simply
define a recursion level - for example we go not deeper than 3 levels of
dependencies, then stop. Hmm, the one sounds hard, the other ugly :)

> [...]
> What about the files/ directory? Wasn't that a major concern?

Sorry. forgot that.
files would look like  a normal directory tree from /

I thought you or Thomas had objections with this, but I don't understand
which ones.

>[...]
> I think this is a really great idea and well thought too, but implementing it
> won't be as easy. We need to try, though.

Thanks. Mainly, these are bigger changes which will require a lot of
testing.

Henning