Hi, > 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. > 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. > If you look at other Fedora-derived distributions, we have a variety > of > installclasses that are used - there is no single 'default'. The default is needed only to enable special features during pre-network stages. I didn't intend to select packages there, only to enable/disable automatic stuff like driver disc detection.. After the repository is initialized, the metadata from that repository will be used. Martin ----- Original Message ----- > Martin Sivak (msivak@xxxxxxxxxx) said: > > I have written a summary of my discussion with dcantrell and dmach > > from release engineering. > > > > https://fedoraproject.org/wiki/Anaconda/Features/InstallClassesInRepo > > Commenting here. If you want it on the feature page, can do that too. > > 1) I think the idea of having this in a package in the repo isn't the > best. > > - It complicates the build/update/modification process for delivery - > you > have to commit to a SCM somewhere, build a package, push an update, > and so > on. > - It complicates the anaconda side - you have to find the magic > package in > the repo, explode it, and put it where you need to read it. > > 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)? > > 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. > > If you look at other Fedora-derived distributions, we have a variety > of > installclasses that are used - there is no single 'default'. > > 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
