1DNF5-SPECS(7) dnf5 DNF5-SPECS(7)
2
3
4
6 dnf5-specs - Patterns Specification
7
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
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
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
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
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
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
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
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
169 RPM boolean dependencies:
170 https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html
171
172
174 See AUTHORS.md in dnf5 source distribution.
175
177 Contributors to the dnf5 project.
178
179
180
181
182 Nov 09, 2023 DNF5-SPECS(7)