#6144: Document the semantics of "comps"

[Fedora Release Engineering]

#6144: Document the semantics of "comps"
---------------------+-----------------------
  Reporter:  rholy   |      Owner:  rel-eng@…
      Type:  defect  |     Status:  new
 Milestone:          |  Component:  other
Resolution:          |   Keywords:
Blocked By:          |   Blocking:
---------------------+-----------------------

Comment (by dcantrel):

 It really would be nice to have the comps specification documented
 somewhere.  Most of the functionality that is understood or expected of
 comps comes from historical research.  Not great, but that's what we have.
 comps do not fit in to the standard RPM metaphor we have because they
 describe RPMs outside of the context of a single RPM.  Development and
 maintenance around comps has always been outside of the standard package
 maintenance model.

 For installation-time behavior, I recommend the kickstart %packages
 documentation:

 https://github.com/rhinstaller/pykickstart/blob/master/docs/kickstart-
 docs.rst#chapter-3-package-selection

 That explains how the installer has treated mandatory, default, and
 optional attributes on packages defined in comps.  In brief:

 1) Mandatory packages are always installed if a user asks for a comp (a
 group in kickstart or installer language).

 2) Default packages are installed, but the user can exclude them.  In the
 graphical installer, these are the packages that would appear checked by
 default but the user could uncheck them.

 3) Optional packages are not installed by default, but the user can select
 them.  The opposite of #2.

 So there are really just two types of packages:  mandatory and user
 selectable.  "default" means the user selectable is flagged for
 installation by default.  "optional" means the package is not flagged for
 installation by default.

 All of this language really only matters when users are working with comps
 definitions.  That is, package groups.  Installing @desktop or
 @development triggers the definitions from comps.  Users can, and
 sometimes do, list individual packages by name in the %packages section.

 As for overlapping comps definitions....this shouldn't happen in comps
 directly, but does happen via RPM dependencies.  A comps definition is
 typically short (except for the translation data) because we know that RPM
 dependencies will pull in a lot of packages.  Comps definitions don't work
 without RPM dependencies.  The appearance of overlapping comps/group
 membership in an RPM is (or should be) the result of RPM dependency
 resolution and not duplicate listing in the comps file.

 Any changes to how comps works with DNF should take in to account the
 established behavior in %packages in kickstart files.  We can change
 things, but we should avoid breaking existing behavior for users.

-- 
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6144#comment:4>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project