Thanks for your answers (and for translating that python bit into human language for me). That is what I had feared, although I had hoped to get better news on the future release compatibility. Since you asked why: I thought it would be nice to have a file containing a "standard" command section which in itself can configure a fully functional client. For clients which deviate a little from the standard, I could then define the different option in their kickstart file and just include the standard without having to worry what is in there. To continue my keyboard example, 95% of all my clients have Japanese keyboards, so the standard would include "keyboard jp106". Only the few clients using US keyboards would then use following kickstart file: ... ... keyboard us ... %include standard.ks ... The "syntactically correct" way would be to have a keyboard definition for each client, and not to define any keyboard in the included standard file. That is, of course, possible, but it has some disadvantages. For example, if the syntax of a value is changed, every kickstart file will have to be updated for upgrades. When using a standard file and only pre-defining the differences, only the single standard file has to be edited. (Such things do happen. For example, the language value for Japanese is changing from ja_JP.eucJP in RH9 to ja_JP.UTF-8 in Severn) So I guess I will have to trade-off checking with each release whether the "undefined behavior" of using the first entry in the commands section still works to finding out which kickstart files I need to edit to accommodate syntax and definition changes. -- Stefan Christians
