| |
@@ -799,8 +799,14 @@
|
| |
(*list*) -- additional packages to be included in a variant and
|
| |
architecture; format: ``[(variant_uid_regex, {arch|*: [package_globs]})]``
|
| |
|
| |
+ In contrast to the ``comps_file`` setting, the ``additional_packages``
|
| |
+ setting merely adds the list of packages to the compose. When a package
|
| |
+ is in a comps group, it is visible to users via ``dnf groupinstall`` and
|
| |
+ Anaconda's Groups selection, but ``additional_packages`` does not affect
|
| |
+ DNF groups.
|
| |
+
|
| |
The packages specified here are matched against RPM names, not any other
|
| |
- provides in the package not the name of source package. Shell globbing is
|
| |
+ provides in the package nor the name of source package. Shell globbing is
|
| |
used, so wildcards are possible. The package can be specified as name only
|
| |
or ``name.arch``.
|
| |
|
| |
@@ -809,6 +815,21 @@
|
| |
it. If you add a debuginfo package that does not have anything else from
|
| |
the same build included in the compose, the sources will not be pulled in.
|
| |
|
| |
+ If you list a package in ``additional_packages`` but Pungi cannot find
|
| |
+ it (for example, it's not available in the Koji tag), Pungi will log a
|
| |
+ warning in the "work" or "logs" directories and continue without aborting.
|
| |
+
|
| |
+ *Example*: This configuration will add all packages in a Koji tag to an
|
| |
+ "Everything" variant::
|
| |
+
|
| |
+ additional_packages = [
|
| |
+ ('^Everything$', {
|
| |
+ '*': [
|
| |
+ '*',
|
| |
+ ],
|
| |
+ })
|
| |
+ ]
|
| |
+
|
| |
**filter_packages**
|
| |
(*list*) -- packages to be excluded from a variant and architecture;
|
| |
format: ``[(variant_uid_regex, {arch|*: [package_globs]})]``
|
| |
ktdreyer
commented 2 years ago
Contrast the
additional_packagessetting with thecomps_filesetting.Explain what happens when a user lists a package in
additional_packagesbut Pungi cannot find it.Give an example of composing all builds in a Koji tag.
Fixes: https://pagure.io/pungi/issue/1525