#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 ausil):

 Replying to [comment:4 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).

 there is a * if the package is not available it is skipped. which we use
 for things like bootloaders. If dnf was to refuse to install a group if a
 package in the group was not available we would need a way to specify in
 comps that the package was manadatory on some subset of arches.

 > 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.

 we definitely should not break any long term expected behaviours.

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