David Lehman (dlehman@xxxxxxxxxx) said: > In theory, what we need is two new meta-group types: variant (aka spin) > and addon. Each is a set of groups. You can only have one variant > selected or installed at any given time. Each variant defines a set of > addons, of which any number may be selected/installed. Regular groups > and packages are only exposed via kickstart, if at all. > > Once we have the groups set up and accompanying kickstart support, the > spins should end up being exactly the same package set as you'd get by > choosing the same variant+addons in the anaconda software selection ui. > The addition of meta-packages and/or kickstart script snippets (perhaps > per variant?) could bridge the gap so that the spins end up identical to > the corresponding anaconda variant/addon selections. > > How does this fit with your proposal and your concerns? I can see this working. Initial concerns: - Would we need to drive the variants and add-ons into first class objects in yum as well (such that, if intstalled, they're marked on the system in some way (yumdb, etc.), and that they can be installed post-install, etc?) The simplest solution is add these as additional sections in the comps file, and parse them with yum's comps module - the question is whether this info is used in yum itself outside of that, or if it's left for higher-level tools. - In RHEL, due to fun with entitlements & certs, add-ons are segmented as separate repos. Your proposal doesn't obviously prevent this, but I think we need to explicitly keep that working. Bill _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
