On Thu, 2008-04-24 at 06:14 -0400, Chris Lumens wrote: > > > - loader should be moving to just doing what is required to fetch and > > > mount the stage2 image. This can perhaps include inferring an > > > installation repo based on the location of the stage2 image, but the > > > > I wouldn't so much say that the loader would infer the installation repo > > location. But that information on where stage2 came from is available > > to stage2 and then we can do munging in stage2 to suggest a repo based > > on that. Or upon a mirrorlist or the like. > > I like this even better because it involves moving stuff out of loader. > We already have the information about where stage2 came from thanks to > the -m <whatever> argument to anaconda. Doesn't seem like there's a > whole lot to do here. Yep > I might still like to pre-populate the URL box in loader with the > mirrorlist, but I haven't thought about how to do that without > hardcoding values. Isn't the hope, though, that the only time[1] you get a prompt in the loader is if you pxe boot (and thus don't have stage2 available). If stage2 is available, we don't need to prompt about repos until we're in the second stage at which point the mirrorlist stuff becomes a lot easier > > > Problem: If the user booted off a CD and we don't have any method > > > configuration screen, the implied updates.img and product.img checks > > > will never work. > > > > The implied updates.img should map to the stage2 location more than the > > repo I think. product.img needs some more thought, though > > updates.img: Sounds good. Anything that decouples loader from the > installation payload sounds good to me at this point. > > 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. Jeremy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
