On Tue, 2006-12-12 at 16:01 -0500, Matthew Miller wrote: > On Tue, Dec 12, 2006 at 03:50:58PM -0500, Jeremy Katz wrote: > > Does this make sense to people and seem like it would help some in > > developing changes as well as doing testing for anaconda? > > Yes, makes sense. You know my constant question, though, which is: how does > this work with install classes? They're highly tied to both anaconda version > *and* to the specifics of what they're installing. The entirety of what the install classes are right now really needs some (okay, lots of) work. Right now, installclasses pull duty as the following: * Defining upgrade vs install * Defining kickstart vs interactive install * Defining type of distro being installed * Default partitioning * Default package selection * Other defaults The first two should certainly not be related at all to the last :-) I'd like to get to where upgrade vs install and kickstart vs not are more inherent to the installation. And then, the current concept of the "installclass" becomes the piece which allows for distribution differentiation[1]. But I don't think that's really a blocker for any of this, since I've managed to sufficiently twist things so that upgrade and kickstart derive from the "real" installclass. After that, I think there's room for some of the distro related pieces (that I think you care about) to be provided by some form of metadata. The big question is really what knobs to provide and then to come up with a nice way of expressing them. And for some of them, maybe the answer ties in with kickstart becoming a data source for defaults (and defaulting to not asking things which are provided) instead of kickstart as an installclass that changes significant chunks of the installer behavior. Jeremy [1] See some of the differences between the Fedora install class and the RHEL one. The install class should also play a big role in deciding the package backend; this is currently just hardcoded.
