Jesse Keating wrote:
On Wednesday 10 January 2007 15:15, Bill Nottingham wrote:
The suggestion is that we need to decide which of these (or something
else) we want to do.
I'd like to hear the Anaconda folks' ideas on how to describe the
customizations to Anaconda, and then we can worry about the methodology to
GET those modifications to where Anaconda could read them.
I think a versioned file with a syntax that's already documented in a
million places. Perhaps XML. Before all the groans, XML is really only
useful for backend stuff like this. Infinite generators could be
written (web pages, PyGTK things, command line tools, etc) to help write
the XML file. We gain the ability to version it should we ever want to
break compatibility (like what clumens has going in pykickstart). But
then that's usually followed by many people citing examples of where XML
ruined their favorite project.
But the more I think about this, the more it sounds like anaconda is
headed down the road of becoming a generic install tool like
InstallShield or something similar rather than specific to our
distributions. Or even specific to installing a distribution. And I
think that would be interesting. Why not aim for that? On that
thought, we can let the above file define what anaconda should ask for
in a Next/Back interface. Provide the triggers that let people prompt
for information that we don't care about in Fedora and RHEL, but that
they care about in whatever.
Of course, there are a million things that would have to happen for
something like this to work, but I don't think it's impossible. If
anaconda was more like an execution engine for this master config file,
maybe it would be useful to more projects. Or, at the very least, more
useful to those projects already maintaining forks.
--
David Cantrell
Red Hat / Westford, MA
