DNF5.CONF-VENDORPOLICY-V1_1(5)

dnf5

DNF5.CONF-VENDORPOLICY-V1_1(5)

NAME¶

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

DESCRIPTION¶

This document describes the structure and syntax of the DNF5 Vendor Change Policy configuration files using version 1.1 format.

For general information about vendor change policy files, see DNF5 Vendor Change Policy File Reference <#dnf5-vendor-change-policy-label>.

FILE STRUCTURE¶

Required Fields¶

version

String

Configuration file format version.

For this format, must be set to "1.1".

This field is mandatory and must be specified at the top level of the TOML file.

Example:

version = '1.1'

Note:

For the configuration file to have any effect on vendor change policy, it must contain at least one of the supported lists (see below): outgoing_vendors, incoming_vendors, equivalent_vendors, outgoing_packages, or incoming_packages.

If the file contains no lists, it will be loaded and its version will be validated, but it will not define any rules and will not affect vendor manager behavior.

Vendor Mapping Definition¶

The following vendor lists can be used to define vendor mappings. All lists are optional and can be freely combined. All conditions are evaluated together.

[[outgoing_vendors]]

Array of tables

List of vendors from which changes are allowed (outgoing package vendors).

[[incoming_vendors]]

Array of tables

List of vendors to which changes are allowed (incoming package vendors).

[[equivalent_vendors]]

Array of tables

List of vendors that are mutually equivalent. Changes are allowed in both directions between all vendors in this list.

Note:

equivalent_vendors is actually a shorthand notation. It is equivalent to listing the same vendors in both outgoing_vendors and incoming_vendors.

Important:

A vendor change during package replacement is allowed only if both conditions are met simultaneously:

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¶

Each entry in [[outgoing_vendors]], [[incoming_vendors]], or [[equivalent_vendors]] can contain the following fields:

vendor

String

Required field.

Vendor name or pattern for matching.

comparator

String

Optional field.

The matching method to use when comparing vendor strings.

Default: "EXACT"

Supported values:

"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" - negated variants

exclude

Boolean

Optional field.

If true, the vendor is excluded from the rule. This is useful for defining exceptions to more general rules. Rules (vendor entries) are processed in the order they are defined. This means that an exclude rule must appear before the rules from which the vendor should be excluded.

Default: false

Package Filtering¶

Vendor change policies can be further restricted to apply only to specific packages using package filters. These are optional and allow fine-grained control over which packages are allowed to change vendors.

[[outgoing_packages]]: Array of tables
List of package filters that restrict which outgoing (installed) packages are allowed to change vendors. If omitted, all packages are allowed to change from their current vendor.
[[incoming_packages]]: Array of tables
List of package filters that restrict which incoming (new) packages are allowed to be installed with a vendor change. If omitted, all packages are allowed to be installed regardless of vendor.

Package Filter Entry Fields¶

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

filters

Array of tables

Required field.

List of filter conditions that must all match for the package to be affected by this rule. Each filter is a table with the following fields:

filter

String

Required field.

The package attribute to filter 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 to match 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 field.

The matching method to use.

Default: "EXACT"

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

Same values as for 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

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 ensures correct version ordering (e.g., "1.10" > "1.9").

Note:

The cmdline_repo filter only supports "EXACT" comparator.

exclude

Boolean

Optional field.

If true, packages matching the filters are excluded from the rule. This is useful for defining exceptions. Exclusion rules must appear before the rules from which packages should be excluded.

Default: false

EXAMPLES¶

Example 1: Allow change from "VendorA" to "VendorB"¶

This example shows the minimal required configuration, allowing a change from "VendorA" to "VendorB", but not the reverse.

version = '1.1'
[[outgoing_vendors]]
vendor = 'VendorA'
[[incoming_vendors]]
vendor = 'VendorB'

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

This example shows allowing a change from any vendor to "My Trusted Vendor", but not the reverse. Missing outgoing_vendors means any vendor is allowed.

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

Example 3: Equivalent vendors¶

This example shows vendors that are mutually equivalent, allowing changes in both directions.

version = '1.1'
# 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¶

This example shows a vendor policy for SUSE-related vendors with an exclusion for openSUSE Build Service.

version = '1.1'
# 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 example demonstrates combining equivalent_vendors with incoming_vendors, a feature introduced in version "1.1". "First Vendor" and "Second Vendor" are mutually equivalent, and both can change to "Third Vendor".

version = '1.1'
[[equivalent_vendors]]
vendor = 'First Vendor'
[[equivalent_vendors]]
vendor = 'Second Vendor'
[[incoming_vendors]]
vendor = 'Third Vendor'

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

This example allows installing packages from the command-line repository from any vendor, bypassing vendor restrictions.

version = '1.1'
[[incoming_packages]]
filters = [


  { filter = 'cmdline_repo', value = 'true' }
]

Example 7: Command-line packages with exclusion¶

This example allows installing packages from the command-line repository from any vendor, except for packages whose names start with "mypackage".

version = '1.1'
[[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¶

This example allows a change from any vendor to "My Vendor", but only for incoming packages whose source package name is "mypackage" and version is greater than or equal to "2.0".

version = '1.1'
[[incoming_packages]]
filters = [


  { filter = 'source_name', value = 'mypackage' },


  { filter = 'version', value = '2.0', comparator = 'GTE' }
]
[[incoming_vendors]]
vendor = 'My Vendor'

Author¶

See AUTHORS.md in dnf5 source distribution.

Copyright¶

Contributors to the dnf5 project.

February 19, 2026

Source file:	dnf5.conf-vendorpolicy-v1_1.5.en.gz (from dnf5 5.4.0.0-1.1)
Source last updated:	2026-02-19T00:00:18Z
Converted to HTML:	2026-03-28T00:48:44Z

NAME¶

DESCRIPTION¶

FILE STRUCTURE¶

Required Fields¶

Vendor Mapping Definition¶

Vendor Entry Fields¶

Package Filtering¶

Package Filter Entry Fields¶

EXAMPLES¶

Example 1: Allow change from "VendorA" to "VendorB"¶

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

Example 3: Equivalent vendors¶

Example 4: Equivalent vendors with an exclusion¶

Example 5: Combining equivalent vendors with incoming vendors¶

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

Example 7: Command-line packages with exclusion¶

Example 8: Allow change from any vendor to specific one with package filtering¶

SEE ALSO¶

Author¶

Copyright¶