> The obvious problem there is that you *have* a kernel selection > algorithm. > Let's just remove that. (Serious here - there is only kernel, and it > works > where it works - it's not like we're backporting this to older > releases > where we didn't have pv_ops.) That would be perfect if we could just kill it. And if pv_ops solve all the cases we have to check now, it just got much better. > Right. We may not *have* the concept of optional packages in F17+, > after > all (that part of anaconda is going away, so what do they serve?) > > Perhaps it's better to split out what we do with install classses > now: > > 1. define tasks (groups of groups, can be selected in the UI) > 2. set some boring metadata strings for the UI > 3. skip steps we don't want to show > 4. set some random configuration parameters (bootloader args? wtf?) > 5. set the installer backend > 6. set the upgrade match list > > Now, it's entirely possible that with what you're talking about, we > split > some of these functions off into different areas. For example, I have > no > idea how we do #3 or #4 in the new anaconda UI world, even with what > you're > proposing. 1. We should really get this away from anaconda sources 2., 3. and 4. I hoped to use the proposed %flags section for such kind of stuff. 5. and 6. I have no idea, I haven't got that far yet :) Parts will obviously be controllable by flags, for some we might need some kind of another section We might use different format for this than kickstart at the end, I based the proposal around it simply because most of the stuff is already there (at least the parser :). > > It surely is, but aren't we doing it with spins right now? Isn't > > every spin just another repository generated by pungi with modified > > kickstart? > > All spins except the weird, bastardized, 'Fedora' spin are live > images, > not repositories. Chris had mentioned an idea of 'fixing' the > infrastructure so that it would be easier in anaconda to select a > spin and > get the right thing, even if you're installing from the network repo. Yep we talked about spin selection in Tempe, but your answer bellow needs to be properly addressed first before that can happen... > > I was actually thinking (unrelated to this, but good time to > > mention > > it :) that spin should really be just a package with dependencies, > > post > > config scripts and maybe some artwork for the spin (kind of > > metapackage..). > > The problem is that our current spin configurations aren't refined > enough now to cleanly separate what of this is 'things that define > this spin', 'things that make any spin work on a live image', and > 'things that make this particular spin work on a live image'. We'd > need some better organization to get there. Sure this need much broader discussion on a different level (FESCo comes in mind). Martin _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
