Re: [Fedora-spins] [Yum-devel] Forwarding on a Fedora discussion - Packaging & installation

[James Antill]

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(a)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.