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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
