Adding a package to a Release Artifact¶
In the event that a Fedora contributor would like to have a package added to an Artifact of a Compose (such as an installer ISO image, a liveCD, Cloud Image, Vagrant, Docker, etc.) that is slated for Release, the following procedures must be followed due to the interdependence of different components within the distro layout.
First, some information on where this all comes from and how things fit together.
There is the concept of the “Install Tree” which is the collection of packages available at install time. This is a vast sub-set of the whole of the Fedora Package Collection and it is the pool of possible packages that is available to end users who choose to customize their install from the Anaconda installer. It is also the pool of possible packages that is available to the fedora-kickstarts kickstart files that are used to generate various components of the compose via pungi which then produces the Release Artifacts.
The Install Tree itself is defined by the comps groups so in order to add a net new package to one of the Release Artifacts, the package must be placed in an appropriate comps xml file. For more information on what specifically defines the “appropriate comps_ xml file” and what kinds of approvals or review might be needed for adding new packages, please see this HowTo.
We will need to edit the comps file specific to the Fedora release we would like
to target. For example, if we were to target Fedora 25 we would edit
comps-f25.xml.in found within the comps git repository and this should be
modified based on the How to edit comps procedure.
If the package that was added is a part of a pre-existing comps group that is already used in the target Release Artifact’s fedora-kickstarts kickstart file then we are done.
However, if there is a new comps group added then we need to include that new comps group in the respective fedora-kickstarts kickstart file similar to the following.
Next we will need to tell pungi Variants data about the new group and it’s
relationship to the corresponding Variant. This information is held in the
Fedora Pungi Configs pagure git forge repository. The file needed to be
variants-fedora.xml and can be viewed from a web browser here.
Once this has been completed, we’re all done.
Verify that the next compose is successful and that the change made didn’t cause any issues. This can be done from the Fedora Product Definition Center which is a central store of information about Composes and their resulting artifacts.