fai class hierarchy brainstorming

[Michael Tautschnig]

[...]
> 
> CLASSNAME/
>   class_scripts/	-> (1)
>     <NR>[-NAME]
>   variables -> (2)
>   package_config -> (3)
>   disk_config (4)
>   debconf (5) a debconf file for that class
>   README (6)
>   hooks/ (7)
>     <TASKNAME>
>     <TASKNAME>
>   depends(8)
>   scripts/ (9)
>     <NR>[-NAME]
>     <NR>[-NAME]
>   version
> 
> 
> And here the explanations:
> 
> (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!

> (2) a file which was before class/CLASSNAME.var
> (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.

> (4) a file that was before: disk_config/CLASSNAME
> (5) a debconf file for that class
> (6) a file containing some info what this class is about
Should not be mandatory, although it is pretty useful.

> (7) the classic hooks directory, only that the files inside don't need
> the classname added again.
> (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!

> (9) the classic scripts directory, only there are no extra
> subdirectories and the CLASSNAME doesn't appear again here.
> (19) file with a version string inside
The same as with the README file...

What about the files/ directory? Wasn't that a major concern?

> 
> This is just a rough idea, I think will try to make an example
> implementation some day 'cause I like to see how it "feels" :)
> 
> What do you think? Anything wrong or good with that?
> 
>
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.

Best regards,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.uni-koeln.de/pipermail/linux-fai-devel/attachments/20060120/23d19f7c/attachment.bin