Re: loader/stage2 interaction

[Jeremy Katz <katzj redhat com>]

On Thu, 2008-05-01 at 22:24 -0400, Elliot Peele wrote:
> On Thu, May 01, 2008 at 09:43:22PM -0400, Jeremy Katz wrote:
> > On Thu, 2008-05-01 at 21:29 -0400, Elliot Peele wrote:
> > > On Thu, May 01, 2008 at 05:12:42PM -0700, Kay Williams wrote:
> > > > > > > product.img:  What prohibits us from doing the same as with the
> > > > > > > updates.img?  The two are arguably really about the same thing -
> > > > making
> > > > > > > modifications to the stage2 image.  The product.img just modifies the
> > > > > > > available installclasses.  That's still modifying anaconda's source
> > > > > > > files if you think about it.
> > > > > > 
> > > > > > Yes, but logically, a product.img is more related to your packages than
> > > > > > to your installer.  Maybe this is just the sign that we need to blow up
> > > > > > install classes like I've been threatening to do for years. 
> > > > >
> > > > > Well I can certainly just remove the code to download them and then
> > > > > you'll have no choices besides fixing product.img or hoping no one ever
> > > > > asks for it back.
> > > > 
> > > > product.img's are quite useful for creating custom spins w/o needing to run
> > > > a full buildinstall.  In our case, we automatically generate them to provide
> > > > custom .buildstamp, installclass, and pixmap files.
> > > 
> > > We do something similar by generating a product.img from a package,
> > > anaconda-custom, which allows customers to customize most any part of
> > > anaconda that they would like. By default we use this to generate a
> > > custom set of pixmaps and a .buildstamp.
> > 
> > The big question (in my mind) is if product.img continues to be the best
> > mechanism for doing things like this.  The sorts of things that get set
> > with a product.img are things that are largely tied to the set of
> > packages being installed.  As we move the repo selection to be _after_
> > all of those things taking effect, I'm not as sure that product.img
> > still makes sense.
> 
> Most of the customizations that I have seen are more than just changing
> package selection. They tend to be things like adding extra install
> steps for configuring customer applications. In fact most of our
> customers don't use package selection at all since they control what
> gets installed through conary groups.

Right, but those applications don't exist in a generic repository -- the
exist in a very specific one.  Hence, the changes are geared towards
"the set of stuff that I'm installing" more than "the installer I used
to do the install"

Jeremy