fai class hierarchy brainstorming

[Henning Sprang]

On Tue, 2006-01-24 at 07:09 +0100, Juergen Kahnert wrote:
On Mon, 23. Jan. 2006 at 22:54:58 +0100, Henning Sprang wrote:
> > On Fri, 2006-01-20 at 18:10 +0100, Juergen Kahnert wrote:
> > So you say having a means of specifying installation order is not
> > useful, right?
> 
> I know only about the kernel-modules problem where this could be
useful,
> but this could be solved with silent_modules. It's not that nice and I
> would like to use dependencies instead, but that's not(?) the way the
> debian package system works.
> 
> Tell me in which other case it could be useful and how you solve
things
> like this:
> > [...]

I took the idea from the discussion with Michael, whom I probably
misunderstood. I didn't worry myself about installation order yet, so I
guess we can dismiss it.

> [...]
>The goal is ok, I'm not sure if this is the best way reaching it.
> 
> For example, did you never used "if ifclass ..." at your scripts? Or
did
> you never used "package install <class>" at your package configs? How
to
> easily rename a class which uses those features?
> 
I actually don't use these, apart from the example classes I copied. I
like to define my installation exactly.

But it wouldn't matter, a class can have a package config file which
mentions two other class names, no problem with the proposed design.
You still have the benefits as long as it doesn't mention it's _own_
name inside :)
Yes, some classes aren't useful without others, and sometimes there can
be a choice of multiple classes to make a class useful. Therefor "or"
dependencies could be used, which at least warn the user in the logs
that one of the other two classes should be defined, also.

I get an idea about the class directory now: in the good old "class"
directory, even in the new architecture, all scripts are located in a
central directory which decides class definition, according to hardware,
hostnames, disk sizes, as usual.
If you install a new class into the "class repository" containing my
proposed hierarchy, you also need to add something in the class
directory, which defines the class for some machines.

How about that?

> Maybe we need a class-management-system, some tools doing things like
> installing, removing, renaming, ... classes or at least helping by
doing
> those tasks.
> 
> 

For the goal of sharing and distributing single classes, nothing is
easier than zipping and sending a directory, compared to using some
script that parses the whole class tree for occurences of a class name
all over the place.

But Jan Jansen sent something like that to the linux-fai list. It's in
my inbox, not forgotten, but I didn't come to try it.

Henning