1DNF5-SPECS(7)                        dnf5                        DNF5-SPECS(7)
2
3
4

NAME

6       dnf5-specs - Patterns Specification
7

DESCRIPTION

9       Different  pattern  matching rules for arguments in *-spec form are de‐
10       fined for operation with each entity type in DNF5. In this section  all
11       rules are described and explained in detail, with examples.
12

GLOBS

14       Pattern  specification  supports  the  same  glob pattern matching that
15       shell does.  The following patterns are supported:
16
17       *      Matches any number of characters.
18
19       ?      Matches any single character.
20
21       []     Matches any one of the enclosed characters. A pair of characters
22              separated  by a hyphen denotes a range expression; any character
23              that falls between those two characters, inclusive, is  matched.
24              If  the  first  character following the [ is a ! or a ^ then any
25              character not enclosed is matched.
26
27       Note: Curly brackets ({}) are not supported. You can still use them  in
28       shells  that  support  them  and let the shell do the expansion, but if
29       quoted or escaped, DNF5 will not expand them.
30

NEVRA MATCHING

32       Each package can be uniquely identified by the NEVRA  string.  It  con‐
33       sists of 5 parts of information:
34
35       Name
36              Package name.
37
38
39       Epoch
40              Epoch number.
41              It is not always included.
42
43
44              The  epoch number overrides other version checking, so it can be
45              used to force the package upgrade over some other one.
46
47       Version
48              Version string.
49              It is not strictly numeric.
50              It is intended to match the upstream software version.
51
52
53       Release
54              Edition string.
55
56
57              It is an information about the particular package build, usually
58              a  number  increased  with  the newer build. It is not connected
59              with the upstream software.
60
61       Architecture
62              Target architecture string.
63              Defines the processor type the package is intended to be installed on.
64
65
66              It can be also a package containing source files (src) or archi‐
67              tecture-independent package (noarch).
68
69       When matching against NEVRAs, partial matching is supported. DNF5 tries
70       to match the spec against the following list of  NEVRA  forms  (in  de‐
71       creasing order of priority):
72
73          NAME-[EPOCH:]VERSION-RELEASE.ARCH
74          NAME.ARCH
75          NAME
76          NAME-[EPOCH:]VERSION-RELEASE
77          NAME-[EPOCH:]VERSION
78
79
80
81       Note   that   name   can   in   general   contain  dashes  (e.g.  pack‐
82       age-with-dashes).
83
84       The first form that matches any packages  is  used  and  the  remaining
85       forms  are  not  tried. If none of the forms match any packages, an at‐
86       tempt is made to match the <package-spec> against full package  NEVRAs.
87       This is only relevant if globs are present in the <package-spec>.
88
89       <package-spec>  matches  NEVRAs  the same way <package-name-spec> does,
90       but in case matching NEVRAs fails, it attempts to  match  against  pro‐
91       vides and file provides of packages as well.
92
93       You  can specify globs as part of any of the five NEVRA components. You
94       can also specify a glob pattern to match over multiple NEVRA components
95       (in  other  words, to match across the NEVRA separators). In that case,
96       however, you need to write the  spec  to  match  against  full  package
97       NEVRAs, as it is not possible to split such spec into NEVRA forms.
98

PACKAGES

100       Many  commands  take  a <package-spec> parameter that selects a package
101       for the operation. The <package-spec> argument is matched against pack‐
102       age NEVRAs, provides and file provides.
103
104       When  <package-spec>  is a package name or a provide, the user can pro‐
105       vide additional restriction rules for  matching  the  arguments.  Basic
106       version  comparisons  can  be  used for this purpose (=, >, <, >=, <=),
107       like this <package-spec> >= <version>, where the <version> argument  is
108       in  a  [EPOCH:]VERSION[-RELEASE] format as specified above in the NEVRA
109       matching section.
110
111       To build more complex expressions, a rich dependency  feature  is  also
112       supported,  which  is always enclosed in parentheses. Boolean operators
113       and nesting can be used, f.e. (<spec1> or (<spec2> and <spec3>)).   For
114       more information, please see RPM boolean dependencies.
115
116       <package-file-spec>  is  similar  to  <package-spec>,  except  provides
117       matching is not performed. Therefore,  <package-file-spec>  is  matched
118       only against NEVRAs and file provides.
119
120       <package-name-spec> is matched against NEVRAs only.
121

PROVIDES

123       <provide-spec>  in  command  descriptions means the command operates on
124       packages providing the given spec. This can either be an explicit  pro‐
125       vide, an implicit provide (i.e. name of the package) or a file provide.
126       The selection is case-sensitive and globbing is supported.
127
128   Specifying File Provides
129       If a spec starts with either / or */, it is considered as  a  potential
130       file provide.
131

GROUPS

133       <group-spec> allows one to select (environment) groups a particular op‐
134       eration should work on. It is a  case  insensitive  string  (supporting
135       globbing  characters)  that  is matched against a group's ID, canonical
136       name and name translated into the current LC_MESSAGES locale (if possi‐
137       ble).
138

MODULES

140       <module-spec> allows one to select modules or profiles a particular op‐
141       eration should work on.
142
143       Since NEVRA  matching  form  is  insufficient  for  modules,  they  are
144       uniquely  identified  by  the  NSVCA  format  (NAME:STREAM:VERSION:CON‐
145       TEXT:ARCH/PROFILE). Supported partial forms are the following:
146
147          NAME
148          NAME:STREAM
149          NAME:STREAM:VERSION
150          NAME:STREAM:VERSION:CONTEXT
151          All above combinations with ::ARCH (e.g. NAME::ARCH)
152          NAME:STREAM:VERSION:CONTEXT:ARCH
153          All above combinations with /PROFILE (e.g. NAME/PROFILE)
154
155
156
157       In case stream is not specified, the enabled or the default  stream  is
158       used,  in this order.  In case profile is not specified, the system de‐
159       fault profile or the 'default' profile is used.
160

TRANSACTIONS

162       <transaction-spec> can be in one of several forms. If it is an integer,
163       it  specifies a transaction ID. Specifying last is the same as specify‐
164       ing the ID of the most recent transaction. The last form is  last-<off‐
165       set>,  where  <offset>  is  a  positive integer. It specifies offset-th
166       transaction preceding the most recent transaction.
167

SEE ALSO

169       RPM boolean dependencies:
170              https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html
171
172

AUTHOR

174       See AUTHORS.md in dnf5 source distribution.
175
177       Contributors to the dnf5 project.
178
179
180
181
182                                 Nov 24, 2023                    DNF5-SPECS(7)
Impressum