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. Greetings Elliot, This might not work for your particular use case, but thought it worth tossing out there. Would firstboot plugins make sense for some of the local customizations you're looking for? NOTE: I'm coming at this from a reducing test paths perspective Thanks, James -- ========================================== James Laska -- jlaska@xxxxxxxxxx Quality Engineering -- Red Hat, Inc. ========================================== _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
