kickstarts and xml

[Philip Rowlands]

On Mon, 23 Feb 2004, seth vidal wrote:

[XML-ize kickstart config]
>You could also, potentially, do cased dependencies in the kickstart -
>which would add flexibility and power.
>
>Is this worth thinking about?

I vote against.

I regard kickstart files as the "66.6%" solution to automated installs.
Not too braindead, not too powerful, but more useful than not.  Where
kickstart doesn't fit the bill, the %pre and %post hooks allow infinite
tinkering.

The raison d'être of a kickstart file is to answer the questions the
installer would ask. What do you want to install? Where am I reading
from? Where am I writing it to? plus enough basic configuration to get
past the first boot and be happily running and networked.

Why add complexity? Do the gains outweigh the costs? With comps.xml, the
i18n issues and package markup persuaded the anaconda developers that
it was a worthwhile change.

Permit me to throw in some "cons" for balance:
- Freeform XML cannot be parsed by coreutils as easily as LF-delimited
files. Automating the automation becomes more difficult, as kickstart
file generators/filters need to be XML-aware.
- Learning curve goes up. Today, the newbie can take the generated
kickstart file from his last install, open up everyone's favourite
s1-kickstart2-options.html, and start to tweak.

If Word can do everything .txt files can (and more!), shouldn't we all
be using Word? (Or domain-specific Markup Languages?) 2 aspirins good, 5
aspirins better?

Do you see the advantage of XML in the robust layout, the expressive
markup available through metadata, or just (duck!) because everything
seems to be moving to use XML these days?

Keep the automated installer small. Keep the complexity down. Put the
intelligence in the tools which write %pre scripts, %post scripts and
kickstart files themselves.

Discuss :)


Cheers,
Phil