Configspace redesign proposal

Concept for a new FAI configspace and class hierarchy

proposal

To make sharing of classes easier, I want to propose an alternative structure of the FAI_CONFIGSPACE.

Currently, if you want to get "everything that belongs to a class", you need to look into many differentr directories, use find and grep.

In my proposed design, everything that belongs to a class is contained in one directory. Still, there could be interdependencies between classes, e.g., the class "MUSICPLAYER" installs a graphical program if the class "GUI" is also defined, and this proposal doesn't have a solution on how to bind these together (excect adding some metdata like "influenced-by" -. similiar to the depends thing)

but the fact that this proposal doesn#t solve all problems

The basic idea looks like this:

1. CLASSNAME/
   1. class_scripts/ -> (1)
      1. <NR>[-NAME]
   2. variables -> (2)
   3. package_config -> (3)
   4. disk_config (4)
   5. debconf (5) a debconf file for that class
   6. README (6)
   7. hooks/ (7)
      1. <TASKNAME>
      2. <TASKNAME>
   8. depends(8)
   9. scripts/ (9)
      1. <NR>[-NAME]
      2. <NR>[-NAME]
   10. version
   11. files
   12. /path/to/file/filename

And here the explanations:

1. The name of the class
   1. the classic class directory
      1. a script which migh automate the definition of this class implicitly
   2. a file containing what was before class/CLASSNAME.var
   3. a directory containing files which define packages needed for that class.
      1. a file describing some packages. It's numbered, or the name is only a

number, to enforce the order of installation.

1. 1. a file that was before: disk_config/CLASSNAME
   2. a debconf preseeding file for that class (how is defined which debconf presseding file overwrites which other one?
   3. an (optional) file containing some info what this class is about
   4. the classic hooks directory, only that the files inside don't need the classname added again.
      1. a hook for the task <TASKNAME>
   5. a file with a list of classes this class depends on
   6. the classic scripts directory, only there are no extra subdirectories and the CLASSNAME doesn't appear again here.
   7. (optional)file with a version string inside
   8. The directory with files for that class. As this contains only files for

exactly this class, it's not necessary anymore to name the final file after the class name.

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?

comments and answers to be discussed

1. comment from Michael Tautschnig about the dir CLASSNAME/class: do we really still need this directory? For this kind of structuring, you need to have the classes defined already
   1. reply from me: hmm, as i moved the variables to an extra file, you are right, I think. I still keep it there now and see if I can really keep it empty in a reference imlementation, then I'll throw it away)
   2. later comment from HS: 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.
2. comment from MT about depends: 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!
   1. reply from HS: we could say that we only solve depends one (or some other number) level deep - so, when "GNOME-DESKTOP" is a class defined directly for an install client, and this depends on "XFREE", it's solved. When "GRAPHICAL_DIFF" depends on GNOME-DESKTOP, the XFREE isn't solved anymore. I think, this can better be answered when having a reference implementation. And, it can be left out in the first place, because it adds functionality we don't have now and probably don't really need. Also, we could try tracking dependency paths and check for cycles - this is a bit too hard probably.
3. comment from Juergen Kahnert(JK) about the goal of this proposal and the
4. level we reach 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? Maybe we need a class-management-system, some tools doing things like installing, removing, renaming, ... classes or at least helping by doing those tasks.
   1. reply from me: right, this proposal doesn't solve all things, but I think it makes at least some things easier. I don't use a lot "ifclass" myself - for people who do, it will not help much in renaming classes, that is right.
5. comment from Michael Tautschnig about the package_config, which was a file in the first draft: let's make this a directory, containing files named like <NR>[-NAME] so we solve the problem of some users to enforce an installation order for some packages
   1. reply from JK: this isn#t needed and in some cases problematic - see the

full thread below.

see further comments: http://www.mail-archive.com/linux-fai-devel@rrz.uni-koeln.de/msg00208.html

comments that went into the proposal

1. comment from MT: README should be optional, although it's pretty useful
2. comment from MT about version string file: useful., but should be optional
3. comment from MT: what about the files directory?