DNF5-SPECS(7)

📦
version 5.4.6.0 · 4 versions
, in fedora 44

✨ DNF5-SPECS(7) ✨

okay bestie, welcome to the dnf5-specs manual page 💖 this is the one that explains Patterns Specification — aka all the little secret languages DNF5 speaks when you hand it a *-spec argument. Different entity types get different pattern matching rules, and this page spells out every single one of them, with examples. no cap. let's go 🫶

🌸 DESCRIPTION 🌸

So, like, every entity type in DNF5 has its own pattern matching rules for arguments in *-spec form. This section describes and explains all of them in detail, with examples. it's giving encyclopedia but make it cute 📚✨

🎀 GLOBS 🎀

Pattern specification supports the same glob pattern matching that the shell does. here's the roster:

  • * — matches any number of characters. slay, wildcard behavior 💅
  • ? — matches any single character. one and only one, bestie.
  • [] — matches any one of the enclosed characters. A pair of characters separated by a hyphen denotes a range expression; any character that falls between those two characters, inclusive, is matched. And if the first character following the [ is a ! or a ^, then any character not enclosed is matched. iconic little negate trick 🔥
Note: Curly brackets ({}) are not supported. You can still use them in shells that support them and let the shell do the expansion, but if quoted or escaped, DNF5 will not expand them. so like, do not come for dnf5 about it, it's the shell's job 😭

👑 PACKAGES 👑

Lots of commands take a <package-spec*> parameter that selects a package for the operation. Depending on the command, the <package-spec*> argument gets matched against these, sequentially until a match is found:

  • NEVRA [N] or case Insensitive NEVRA [NI]
  • Provides [P]
  • File provides [F]
  • Binaries [B]

fr fr, in that order. For example <package-spec-NP> is first matched against NEVRAs and if no matching NEVRA is found it is matched against Provides. main character energy: NEVRA goes first every time 💅

When filtering by Provides [P], the user can specify additional restriction rules for matching the arguments. Basic version comparisons can be used for this purpose (=, >, <, >=, <=), like this: <provide> >= <version>, where the <version> argument is in a [EPOCH:]VERSION[-RELEASE] format as specified in the NEVRA matching section. 👀

To build more complex provides expressions, a rich dependency feature is supported. It is always enclosed in parentheses and boolean operators and nesting can be used, f.e. (<provide1> or (<provide2> and <provide3>)). For more information, please see RPM boolean dependencies. nesting? we love to see it 🪆

🦋 NEVRA matching 🦋

Each package can be uniquely identified by the NEVRA string. It consists of 5 parts of information:

  • Name — Package name.
  • Epoch — Epoch number. It is not always included. The epoch number overrides other version checking, so it can be used to force the package upgrade over some other one. she's powerful like that 👑
  • Version — Version string. It is not strictly numeric. It is intended to match the upstream software version.
  • Release — Edition string. It is an information about the particular package build, usually a number increased with the newer build. It is not connected with the upstream software.
  • Architecture — Target architecture string. Defines the processor type the package is intended to be installed on. It can be also a package containing source files (src) or architecture-independent package (noarch).

When matching against NEVRAs, partial matching is supported. DNF5 tries to match the spec against the following list of NEVRA forms (in decreasing order of priority):

NAME-[EPOCH:]VERSION-RELEASE.ARCH
NAME.ARCH
NAME
NAME-[EPOCH:]VERSION-RELEASE
NAME-[EPOCH:]VERSION

Note that name can in general contain dashes (e.g. package-with-dashes). 🙈

The first form that matches any packages is used and the remaining forms are not tried. If none of the forms match any packages, an attempt is made to match the <package-spec> against full package NEVRAs. This is only relevant if globs are present in the <package-spec>.

You can specify globs as part of any of the five NEVRA components. You can also specify a glob pattern to match over multiple NEVRA components (in other words, to match across the NEVRA separators). In that case, however, you need to write the spec to match against full package NEVRAs, as it is not possible to split such spec into NEVRA forms. globs across separators? highkey unhinged but valid ✨

🌈 File Provides matching 🌈

If a spec starts with either / or */, it is considered as a potential file provide. that's the whole vibe check right there 🎯

⭐ Binaries matching ⭐

Whether to consider package binaries during matching. Checks if given spec is a binary in /usr/bin/ or /usr/sbin/. cute, quick, done 💅

🧚 COMPS 🧚

<group-spec>``|``<environment-spec> allows one to select groups|environments a particular operation should work on. It is a case insensitive string (supporting globbing characters) that is matched against a group's|environment's ID, canonical name and name translated into the current LC_MESSAGES locale (if possible). tripled matched, she does it all 💖

Comps specs are prefixed by @ for commands that also accept package specs. For example see dnf5-install(8), Install Command <# install-command-ref-label>.

The group and environment commands accept both <group-spec> and <environment-spec>, but prefer only their corresponding type in case both groups and environments match the given argument. Other commands that accept both types affect both groups and environments. 🫶

💜 MODULES 💜

<module-spec> allows one to select modules or profiles a particular operation should work on.

Since NEVRA matching form is insufficient for modules, they are uniquely identified by the NSVCA format (NAME:STREAM:VERSION:CONTEXT:ARCH/PROFILE). Supported partial forms are the following:

NAME
NAME:STREAM
NAME:STREAM:VERSION
NAME:STREAM:VERSION:CONTEXT
All above combinations with ::ARCH (e.g. NAME::ARCH)
NAME:STREAM:VERSION:CONTEXT:ARCH
All above combinations with /PROFILE (e.g. NAME/PROFILE)

In case stream is not specified, the enabled or the default stream is used, in this order. In case profile is not specified, the system default profile or the 'default' profile is used. the fallback chain ate, no crumbs left 🍓

🔥 TRANSACTIONS 🔥

<transaction-spec> can be in one of several forms:

  • If it is an integer, it specifies a transaction ID.
  • Specifying last is the same as specifying the ID of the most recent transaction.
  • The last form is last-<offset>, where <offset> is a positive integer. It specifies the offset-th transaction preceding the most recent transaction. ⏪

🎀 SEE ALSO 🎀

🌸 Author 🌸

See AUTHORS.md in dnf5 source distribution. 👑

Contributors to the dnf5 project.

and that's the whole page, bestie!! 🫶✨ this is the dnf5 manual, DNF5-SPECS(7), dated Sep 24, 2026. go forth and match some patterns, you absolute icon 💅🎀

📦 where this page comes from