DNF5.CONF-VENDORPOLICY-V1_1(5)

πŸ“¦
version 5.4.6.0 Β· 2 versions
, in fedora 44

πŸŽ€ DNF5.CONF-VENDORPOLICY-V1_1 πŸŽ€

okay bestie, welcome to the manual page for dnf5.conf-vendorpolicy-v1_1 β€” it's section 5, it's part of the dnf5 fam, and it's literally the whole lore drop on DNF5 Vendor Change Policy File Reference - v1.1. grab a snack, we're going in πŸ’…


✨ NAME ✨

dnf5.conf-vendorpolicy-v1_1 β€” DNF5 Vendor Change Policy File Reference - v1.1


🌸 DESCRIPTION 🌸

So this doc? It's the blueprint for how the DNF5 Vendor Change Policy config files are structured and written β€” specifically the version 1.1 and version 1.2 formats. πŸ¦‹

And here's the tea: version 1.2 is identical to version 1.1, the only glow-up is that it adds support for some extra negated string comparators (scroll down to v1.2 comparators, you'll see them, they're iconic).

If you want the general 411 about vendor change policy files (not just the version-specific structure), that lives in the DNF5 Vendor Change Policy File Reference <#dnf5-vendor-change-policy-label>. πŸ‘‘


🧚 FILE STRUCTURE 🧚

πŸ’– Required Fields πŸ’–

version

String β€” yes, it's a string, don't come at me.

This is the configuration file format version, and it must be set to "1.1" or "1.2". No other vibes accepted.

This field is mandatory and it has to be chilling at the top level of the TOML file. Don't nest it, don't hide it, main character only.

Example:

version = '1.2'
Note: for this config file to actually do anything to your vendor change policy, it has to contain at least one of the supported lists (they're listed below, keep scrolling): outgoing_vendors, incoming_vendors, equivalent_vendors, outgoing_packages, or incoming_packages. If the file has no lists at all, it still gets loaded and its version still gets validated β€” but it won't define any rules and it won't affect vendor manager behavior. It's basically a file that showed up to the party and said nothing. 😭

πŸ¦‹ Vendor Mapping Definition πŸ¦‹

These vendor lists are how you define vendor mappings. Every single one of them is optional and you can freely combine them however you like β€” they all get evaluated together, no cap.

  • [[outgoing_vendors]] β€” Array of tables. A list of vendors that changes are allowed to go from (these are your outgoing package vendors).
  • [[incoming_vendors]] β€” Array of tables. A list of vendors that changes are allowed to go to (your incoming package vendors).
  • [[equivalent_vendors]] β€” Array of tables. A list of vendors that are mutually equivalent β€” changes are allowed in both directions between all the vendors in this list. Everyone's equal here. ✨
Note: equivalent_vendors is lowkey just a shorthand notation. It's equivalent to listing the exact same vendors in both outgoing_vendors and incoming_vendors. Same energy, fewer lines. πŸ’…
Important: a vendor change during a package replacement is allowed only if both conditions are met simultaneously β€” like, both, at the same time, no exceptions: - The vendor of the outgoing (installed) package is listed in outgoing_vendors or equivalent_vendors β€” or both outgoing_vendors and equivalent_vendors are missing, which allows any vendor - The vendor of the incoming (new) package is listed in incoming_vendors or equivalent_vendors β€” or both incoming_vendors and equivalent_vendors are missing, which allows any vendor

🌈 Vendor Entry Fields 🌈

Every entry inside [[outgoing_vendors]], [[incoming_vendors]], or [[equivalent_vendors]] can contain these fields:

  • vendor β€” String. Required field, bestie, you gotta have it. This is the vendor name or pattern that gets matched.
  • comparator β€” String. Optional. It's the matching method used when comparing vendor strings. Default: "EXACT".

Supported values, all of them, let's go:

  • "EXACT" β€” exact match (case-sensitive)
  • "IEXACT" β€” exact match (case-insensitive)
  • "GLOB" β€” glob pattern (case-sensitive)
  • "IGLOB" β€” glob pattern (case-insensitive)
  • "REGEX" β€” regular expression (case-sensitive)
  • "IREGEX" β€” regular expression (case-insensitive)
  • "CONTAINS" β€” contains string (case-sensitive)
  • "ICONTAINS" β€” contains string (case-insensitive)
  • "STARTSWITH" β€” starts with (case-sensitive)
  • "ISTARTSWITH" β€” starts with (case-insensitive)
  • "ENDSWITH" β€” ends with (case-sensitive)
  • "IENDSWITH" β€” ends with (case-insensitive)
  • "NOT_EXACT", "NOT_IEXACT", "NOT_GLOB", "NOT_IGLOB", "NOT_CONTAINS", "NOT_ICONTAINS" β€” the negated variants, the "not me" girlies πŸ™ˆ

Additional negated comparators available in version 1.2 (this is the whole 1.2 upgrade, slay):

  • "NOT_STARTSWITH" β€” does not start with (case-sensitive)
  • "NOT_ISTARTSWITH" β€” does not start with (case-insensitive)
  • "NOT_ENDSWITH" β€” does not end with (case-sensitive)
  • "NOT_IENDSWITH" β€” does not end with (case-insensitive)
  • "NOT_REGEX" β€” does not match regular expression (case-sensitive)
  • "NOT_IREGEX" β€” does not match regular expression (case-insensitive)
  • exclude β€” Boolean. Optional. If it's true, the vendor is excluded from the rule. This is your go-to for defining exceptions to more general rules. And listen β€” rules (vendor entries) are processed in the order they are defined, so an exclude rule has to appear before the rules you want that vendor excluded from. Order matters, fr fr. Default: false.

πŸŽ€ Package Filtering πŸŽ€

You can also restrict vendor change policies so they only apply to specific packages, using package filters. These are optional and they give you fine-grained control over which packages are allowed to change vendors. Obsessed with the precision, honestly. πŸ’–

  • [[outgoing_packages]] β€” Array of tables. A list of package filters that restrict which outgoing (installed) packages are allowed to change vendors. If you omit this, all packages are allowed to change from their current vendor.
  • [[incoming_packages]] β€” Array of tables. A list of package filters that restrict which incoming (new) packages are allowed to be installed with a vendor change. If you omit this, all packages are allowed to be installed regardless of vendor.

⭐ Package Filter Entry Fields ⭐

Each entry inside [[outgoing_packages]] or [[incoming_packages]] can contain:

  • filters β€” Array of tables. Required field. It's a list of filter conditions that all have to match for the package to be affected by this rule. Every filter is a table with the following fields:
    • filter β€” String. Required field. This is the package attribute you're filtering on.

Supported values:

  • "name" β€” package name
  • "source_name" β€” source package name
  • "evr" β€” Epoch-Version-Release string
  • "epoch" β€” epoch number
  • "version" β€” version string
  • "release" β€” release string
  • "arch" β€” package architecture
  • "repoid" β€” repository ID
  • "cmdline_repo" β€” whether the package is from command-line repository (boolean)
  • value β€” String. Required field. The value you're matching against.
    • For cmdline_repo filter, use "true"/"1" or "false"/"0"
    • For epoch filter, use a numeric string (e.g., "0", "1")
    • For other filters, use appropriate string values
  • comparator β€” String. Optional. The matching method to use. Default: "EXACT".

For string-based filters (name, source_name, arch, repoid):

Same values as for the vendor comparator: EXACT, NOT_EXACT, IEXACT, NOT_IEXACT, CONTAINS, NOT_CONTAINS, ICONTAINS, NOT_ICONTAINS, STARTSWITH, ISTARTSWITH, ENDSWITH, IENDSWITH, REGEX, IREGEX, GLOB, NOT_GLOB, IGLOB, NOT_IGLOB

Version 1.2 additionally supports: NOT_STARTSWITH, NOT_ISTARTSWITH, NOT_ENDSWITH, NOT_IENDSWITH, NOT_REGEX, NOT_IREGEX

For version-based filters (evr, epoch, version, release):

  • "EXACT" β€” equal to
  • "NOT_EXACT" β€” not equal to
  • "GT" β€” greater than
  • "GTE" β€” greater than or equal to
  • "LT" β€” less than
  • "LTE" β€” less than or equal to
Note: version-based filters use proper RPM version comparison semantics instead of lexical string comparison. This is the good stuff β€” it makes sure version ordering is actually correct (e.g., "1.10" > "1.9"). 🧠
Note: the cmdline_repo filter only supports the "EXACT" comparator. That's it, that's the whole menu.
  • exclude β€” Boolean. Optional. If it's true, packages matching the filters are excluded from the rule. Perfect for defining exceptions. And just like before: exclusion rules must appear before the rules from which packages should be excluded. Default: false.

part 1 done, bestie β€” more incoming, don't go anywhere πŸ’œ

✨ EXAMPLES ✨

Okay bestie, this is the part where it all clicks, I promise. Eight whole examples, from baby's-first-policy to full main character config. Let's go πŸ’…


πŸŽ€ Example 1: Allow change from "VendorA" to "VendorB"

This one's the absolute minimum you need to make it work. It lets a change happen from "VendorA" to "VendorB", and not the reverse. One-way street, no u-turns, no cap.

version = '1.2'

[[outgoing_vendors]]
vendor = 'VendorA'

[[incoming_vendors]]
vendor = 'VendorB'

🌸 Example 2: Allow change from any vendor to "My Trusted Vendor"

Now we're letting any vendor switch to "My Trusted Vendor", but still not the reverse. The trick? If you just... don't write an outgoing_vendors section, then any vendor is allowed. Absence = permission, iconic behaviour tbh.

version = '1.2'

[[incoming_vendors]]
vendor = 'My Trusted Vendor'

πŸ¦‹ Example 3: Equivalent vendors

Here we've got vendors that are mutually equivalent, so changes can go in both directions. They're all in the same little friend group 🫢

version = '1.2'

# All following vendors are mutually equivalent
[[equivalent_vendors]]
vendor = 'Fedora Project'

[[equivalent_vendors]]
vendor = 'Red Hat'
comparator = 'ISTARTSWITH'

[[equivalent_vendors]]
vendor = 'CentOS'
comparator = 'ISTARTSWITH'

πŸ’œ Example 4: Equivalent vendors with an exclusion

A vendor policy for SUSE-related vendors, except openSUSE Build Service gets excluded from the group chat πŸ™ˆ That's what exclude = true is doing there.

version = '1.2'

# All following vendors are mutually equivalent except excluded ones
[[equivalent_vendors]]
vendor = 'openSUSE Build Service'
comparator = 'ISTARTSWITH'
exclude = true

[[equivalent_vendors]]
vendor = 'SUSE'
comparator = 'ISTARTSWITH'

[[equivalent_vendors]]
vendor = 'openSUSE'
comparator = 'ISTARTSWITH'

⭐ Example 5: Combining equivalent vendors with incoming vendors

This one combines equivalent_vendors with incoming_vendors β€” a feature that got introduced in version "1.1", so keep an eye on your version bestie. "First Vendor" and "Second Vendor" are mutually equivalent, and both of them can change to "Third Vendor". Slay.

version = '1.2'

[[equivalent_vendors]]
vendor = 'First Vendor'

[[equivalent_vendors]]
vendor = 'Second Vendor'

[[incoming_vendors]]
vendor = 'Third Vendor'

🧚 Example 6: Allow command-line packages from any vendor

Packages coming from the command-line repository? From any vendor? Yes. This bypasses vendor restrictions entirely for those. Rude, but valid.

version = '1.2'

[[incoming_packages]]
filters = [
  { filter = 'cmdline_repo', value = 'true' }
]

🌈 Example 7: Command-line packages with exclusion

Basically Example 6 but with boundaries πŸ’… Packages from the command-line repository are allowed from any vendor β€” except packages whose names start with "mypackage". Those are on time-out.

version = '1.2'

[[incoming_packages]]
filters = [
  { filter = 'name', value = 'mypackage', comparator = 'STARTSWITH' }
]
exclude = true

[[incoming_packages]]
filters = [
  { filter = 'cmdline_repo', value = 'true' }
]

πŸ”₯ Example 8: Allow change from any vendor to specific one with package filtering

The finale, the main character moment πŸ‘‘ Changes from any vendor to "My Vendor" are allowed, but only for incoming packages where the source package name is "mypackage" and the version is greater than or equal to "2.0". Very specific. Very demure. Very mindful.

version = '1.2'

[[incoming_packages]]
filters = [
  { filter = 'source_name', value = 'mypackage' },
  { filter = 'version', value = '2.0', comparator = 'GTE' }
]

[[incoming_vendors]]
vendor = 'My Vendor'

🫢 SEE ALSO 🫢

  • DNF5 Vendor Change Policy File Reference <#dnf5-vendor-change-policy-label>
  • DNF5 Vendor Change Policy File Reference - v1.0 <#dnf5-vendor-change-policy-v1-0-label>
  • dnf5.conf(5), DNF5 Configuration Reference <#dnf5-conf-label>

πŸ’– Author πŸ’–

See AUTHORS.md in dnf5 source distribution. (They cooked, fr fr.)

Contributors to the dnf5 project.


And that's a wrap bestie!! πŸŽ€ This page is DNF5.CONF-VENDORPOLICY-V1_1(5) β€” the Sep 24, 2026 edition β€” and it lives in the dnf5 source distribution. Go forth and vendor-policy responsibly, ily πŸ’–βœ¨
πŸ“¦ where this page comes from