Martin Sivak (msivak@xxxxxxxxxx) said: > > Obviously they should be on the list. :) But by that argument, > > shouldn't > > the certificate be packaged too? > > Well before this goes completely the wrong direction. The package section > modification was meant to allow for the kernel selection algorithm to work, > not to replace comps mandatory and optional flags. 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.) > I wasn't really thinking about how the user selects tasks when I was > sketching this, but we might provide multiple annotated kickstarts (with > one or two groups each) in the package, show the titles in GUI and let > the user select. But that would be wandering to comps territory again. 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. > > With my Fedora rel-eng hat on, "ugh". Having to have separate > > repositories > > just to contain group data + 1 package seems like overkill. > > 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. > 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. Bill _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
