Martin Sivak (msivak@xxxxxxxxxx) said: > > Why wouldn't we just include the data we need *in* the repository > > metadata > > (either directly as a structured form in the comps file, or as an > > adjunct > > bit of data referenced in repomd.xml)? > > We were discussing this and this was my first idea too. But Dan MAch expressed > concerns about versioning, because customers sometime request updated metadata > and want to see the info in errata. Package can be versioned and but in the errata > using existing processes. An errata to change the product composition? That seems weird - we don't do that now. > > 2) The idea of a default kickstart that this is using I'm not sure > > fits with > > our current production framework, where we have a variety of products > > we > > produce in a release (Desktop, KDE, Games, etc.) - these would *each* > > be a > > top level object, and there is no single 'default' that can be used - > > unless > > we go to a method where we actually have separate repos based on what > > you're > > installing. > > 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. Bill _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
