addpackages removed in FAI 2.9?

[henning]

Hi,

Michael Tautschnig wrote:
>> On Wed, 2005-12-28 at 19:16 +0100, Thomas Lange wrote:
>>     
>>> This wouldn't make sense for the files/ directory tree. Maybe it's
>>> useful for the other directories. But IMO this would change FAI a lot.
>>> But it's up to you to try it and send us your experiences with another
>>> layout of the whole config space.
>>>       
>> This idea is just stolen from yourself :)
>>
>> I think it is problematic with "class", but don't understand what's the
>> problem with files.
>>
>>     
> Do you think it would be useful for any directory but "files"? 
 >[...]

Yes. I could distribute, exchange, and update filey, scripts, package 
configs belonging to a single class that way. I could even package 
classes in *.debs.

>   
>> Are there other ideas to achieve better updateability and shareability
>> of classes? I think that's an important thing.
>>
>>     
>
> Indeed it is, but at least as far as my config space is concerned, I do have
> many files that are shared between classes, e.g., MAILRELAY is also a SERVER and
> thereby gets the relevant ssh configuration, PAM settings ... So if somebody
> were interested in a single class of our configuration, I'd rather have to
> compute the list of classes and then do
>
> for i in $classes ; do
>   find files/ -name $i | xargs -n 1 dirname
> done
>
> to get the list of affected files.
>   

That's another missing thing in FAI, something like management of 
dependenciey between classes. But just because you have nothing like 
that, it doesn't mean we should not make progress in another area, and 
still keepo tracking dependencies manually.

It's a major problem that we support some things via our example 
configs, but in fact, as soon as you have invested a decent amount of 
time into developing you own config space, it's nearly impossible to 
keep a custom configspace in sync with the simple examples  - but then 
eventually things brake when you update to a new FAI version.

> Maybe the way you organize your configuration is quite different and your
> approach suits a lot better, but it does not for me.
No, my current CONFIGDIR would also need lots of reworkings to get 
started with this new design, but see below :)

>  Yet, there was another
> point in the previous discussion: Considering only subdirectories that are very
> specific to a single class, e.g., /etc/apache2 for WEBSERVER - that seems indeed
> useful for me too, but as a result only a mixed structure of files/ and
> new_files/ would be sensible.
>   
It should be no problem to support two type of configspaces, anyway. One 
exactly as the old one, another one where everything starts with 
CLASSNAMES, then the normal structure. Both get parsed.

Interesting in that discsussion: thomas says, having files in a 
structure as proposed by me is not good. I say, maybe class in such a 
structure can make problems, you say, only files makes sense in such a 
structure... :)

Henning