docs: Mention how input package list are interpreted
It's really just an RPM name, not any random provide or source package name. Fixes: https://pagure.io/pungi/issue/725 Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
This commit is contained in:
parent
adaab46bf7
commit
04836cfa9f
@ -603,10 +603,16 @@ Options
|
||||
(*list*) -- additional packages to be included in a variant and
|
||||
architecture; format: ``[(variant_uid_regex, {arch|*: [package_globs]})]``
|
||||
|
||||
The packages specified here are matched against RPM names, not any other
|
||||
provides in the package not the name of source package.
|
||||
|
||||
**filter_packages**
|
||||
(*list*) -- packages to be excluded from a variant and architecture;
|
||||
format: ``[(variant_uid_regex, {arch|*: [package_globs]})]``
|
||||
|
||||
The packages specified here are matched against RPM names, not any other
|
||||
provides in the package not the name of source package.
|
||||
|
||||
**filter_system_release_packages**
|
||||
(*bool*) -- for each variant, figure out the best system release package
|
||||
and filter out all others. This will not work if a variant needs more than
|
||||
|
@ -12,6 +12,10 @@ The inputs for gathering are defined by the ``gather_source`` option. It
|
||||
provides a list of package names, comps groups names and a list of packages
|
||||
that should be filtered out.
|
||||
|
||||
.. note::
|
||||
The inputs for both explicit package list and comps file are interpreted as
|
||||
RPM names, not any arbitrary provides nor source package name.
|
||||
|
||||
Next, ``gather_method`` defines how the list is processed. For ``nodeps``, the
|
||||
results from source are used pretty much as is [#]_. For ``deps`` method, a
|
||||
process will be launched to figure out what dependencies are needed and those
|
||||
|
Loading…
Reference in New Issue
Block a user