[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Trying to break the anaconda/distro embrace



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]