> > This has to be discussed with release engineering then. > > 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 RPM in question will then contain a bit of logic (when/unless) we have in anaconda right now (kernel selection) and thus versioning it is something we might really consider. 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. > 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? 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..). Martin ----- Original Message ----- > Martin Sivak (msivak@xxxxxxxxxx) said: > > > An errata to change the product composition? That seems weird - > > > we > > > don't do > > > that now. > > > > This has to be discussed with release engineering then. > > Obviously they should be on the list. :) But by that argument, > shouldn't > the certificate be packaged too? > > > > > I am not exactly following here. This is not replacing comps > > > > groups, > > > > install data only select the groups and the kickstart will do > > > > much > > > > the same > > > > we do now: Select the default setup for installation. > > > > > > But we don't have a single default install class. We have > > > multiple > > > (or no) > > > defaults - we have a KDE desktop spin, a GNOME spin, etc. - each > > > of > > > these > > > have different defaults. For that other product, we have multiple > > > install > > > classes, all of which has different default groups and > > > parameters. > > > > We do not do anything like this now either.. Right now anaconda > > uses default comps. > > Yes, but even those default values are filtered through the task > lists > defined in the install classes, which overrides them in strange and > not-always-predictable ways. > > > So yes, I was thinking that in this regard each product has it's > > own repository. > > With my Fedora rel-eng hat on, "ugh". Having to have separate > repositories > just to contain group data + 1 package seems like overkill. > > Bill > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list > _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
