On Fri, 2012-03-02 at 14:13 -0500, Bill Nottingham wrote:

Forwarding this along, as we may need yum changes for what's being proposed here. See the questions at the end, especially.

Thought about it a bit, hopefully not lost the plot...

[...]

David Lehman (dlehman@redhat.com) said: Bill Nottingham wrote:

...

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.

Yeh, we basically have four general approaches (that I can see/think-of):

1. Have yum.comps parse out the new "variant" and "add-on" groups, providing some API way to see what they are ... but have anaconda map those to groups, and just have the yum internals (including the new groups as objects code) know about the groups.

pros: p1. This is a trivial yum change. p2. Kind of easy to explain as "this is an install thing", post install just use groups. cons: c1. Yum won't be able to "upgrade" a variant/add-on if new groups are desired to be added post install. c2. Yum won't be able to "install" a variant/add-on post install. c3. Kickstart will have to do @foo lookups before passing them to yum (or not have variant/add-on installs via. kickstart). c4. Nothing will be able to know what variant/add-ons were installed.

2. #1 but also have yum do the variant/add-on mapping ... we mostly keep p1/c1/c4 from #1 but we can install post and can easily have them in kickstart. But it's harder to explain where the line is, and it's basically the same mistake we made with current groups (people expect them to not just be references, but that's what they are).

3. Have yum.comps create new groups, containing packages, for the variant/add-ons. anaconda/etc. will just tell yum to install the variant but it'll be a single giant group containing all the packages.

pros: p1. Again, fairly trivial change. p2. Kind of easy to explain as "these are just groups, that are created a bit special". p3. Yum can install them post install. p4. Yum can upgrade them post install (ie. add groups/packages to an add-on and "yum upgrade" will get them). p5. Not much needs to be done to anaconda. p6. User/API/whatever can mostly see which variant/add-ons were installed, assuming it knows what it is looking for (Eg. current GUIs will mostly show it, albeit in a somewhat confusing way). cons: c1. Add-ons will mostly _be_ groups. Eg. with "groups as objects" packages can only belong to a single group (don't ask for this to change, unless you have patches). This means that if you have an add-on called "Developer Workstation" which includes "gnome-desktop" and "rhel-developer" ... then the later two groups _won't_ be installed, just the single "Developer Workstation" group will be (but it'll automatically contain all the packages of all the groups it refers to -- so "upgrade" will work the same it'll just look "different").

4. Have yum.comps create variant/add-on "groups", containing just references to other groups.

pros: p1. Yum can install them post install. p2. Yum can upgrade them post install (ie. add groups/packages to an add-on and "yum upgrade" will get them). p3. User/API/whatever can see which variant/add-ons were installed easily (Eg. subscription manager might have a _much_ easier time). p4. Groups still exist, and are what a package belongs to. p5. Not much needs to be done to anaconda. cons: c1. A bunch more code has to be written, to save/integrate these special groups into yum (so Eg. "install @foo" does multiple lookups). Esp. need to save them specially. c2. A bunch more code would need to be written for any GUIs to show these special groups, and how you can manipulate them. c3. We have a tree mapping: variant _ group1 => package _ group2 => package add-on1 _ group3 => package _ group4 => package _ group5 => package

...which we'll need to make the user aware of, and is not as simple concept wise.

...option #4 seems "obviously" the best, where even c1 and c2 are really just specific instances of c3 ... but it is the most code, and a big model change. #2 and #3 seem like hacks, but hacks with somewhat desirable behaviour ... #1 is the "this will cleanup anaconda code, but not really change much else" option.