Martin Sivak (msivak@xxxxxxxxxx) said: > > 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 No objection to that. I think it likely can be separate from most of the other items, and we need to figure out, in the context of spins, etc. what the best form & location for this data is. Given the UI redesign, I'm not even sure we would have the concept of 'tasks' as they currently exist. > 2., 3. and 4. I hoped to use the proposed %flags section for such kind of stuff. OK. #2 is text shown on the task screen; we can punt that handling until we figure out tasks for #1. #3, in the examples I have, is skipping filtertype, as a hack to disable certain install targets. It's highly anaconda-version specific, and I don't know if we want to, or need to, support that going forward. #4 we could use flags. We'd need to define what sort of flags we need, as, like with #3, what's done with this currently is taking advantage of being able to frob random things in the anaconda runtime data. > 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 #5 is ideally set automatically from the method/repo URL? Dunno. #6 ... should probably find a better way in general to handle this. Bill _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
