VendorChangeManager: Configuration version `1.1` with package-based filtering and enhanced flexibility #2579

jrohel · 2026-01-20T17:26:08Z

This PR introduces version 1.1 of the Vendor Change Manager configuration format, bringing improvements in flexibility and usability while maintaining full backward compatibility with version 1.0.

Closes: #2544
CI tests for new features: rpm-software-management/ci-dnf-stack#1817

Summary of changes

1. Simplified vendor array rules

Combine equivalent_vendors with directional arrays:
- Version 1.1 allows mixing equivalent_vendors with outgoing_vendors/incoming_vendors for more flexible policies (Note: equivalent_vendors is automatically expanded to both outgoing_vendors and incoming_vendors)
- Version 1.0 restricted this combination
Independent vendor arrays: outgoing_vendors and incoming_vendors can now be specified independently
- Missing array implies "any vendor is allowed"
- Version 1.0 required both arrays to be present or both missing

2. Package-based filtering (new feature)

Added incoming_packages and outgoing_packages arrays to restrict vendor changes based on package attributes
Supported package filters:
- name, source_name, arch, repoid (string-based)
- evr, epoch, version, release (version-based with proper RPM comparison)
- cmdline_repo (boolean)
String comparators: EXACT, IEXACT, CONTAINS, STARTSWITH, ENDSWITH, REGEX, GLOB (and negated variants)
Version comparators: EXACT, NOT_EXACT, GT, GTE, LT, LTE (with proper RPM version ordering)
Exclusion support: Rules can be marked with exclude = true for defining exclusion

3. Backward compatibility

Version 1.0 configurations continue to work unchanged
All version 1.0 restrictions remain enforced for 1.0 configs
Upgrade to 1.1 is opt-in via the version field

4. Improved validation

Vendor regex patterns are now validated during config file parsing
Errors are caught early rather than during goal resolution

5. Enhanced documentation

Documented improvements
Examples for new features
Documented config file locations and ordering rules (.conf extension requirement)

Examples

Allow any vendor to be replaced by "My Trusted Vendor".

version = '1.1'

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

Allow: Mutual changes between "First Vendor" and "Second Vendor" (equivalent vendors), change from "First Vendor"/"Second Vendor" to "Third Vendor"

version = '1.1'

[[equivalent_vendors]]
vendor = 'First Vendor'

[[equivalent_vendors]]
vendor = 'Second Vendor'

[[incoming_vendors]]
vendor = 'Third Vendor'

Allow use packages from the command-line repo from any vendor:

version = '1.1'

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

Allow use packages from the command-line repo 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' }
]

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'

evan-goode

I took a look but have yet to test this. It seems quite powerful!

@Conan-Kudo @michel-slm wdyt?

Allow use packages from the command-line repo from any vendor:

We probably want this by default, will we ship this as a configuration file downstream in Fedora?

evan-goode · 2026-01-21T20:28:26Z

doc/dnf5.conf-vendorpolicy.5.rst

 --------------------------

-The file must contain **one** of the following definition methods:
+The file can use one or more of the following vendor definition methods.


I would rather not mix the documentation for version 1.0 and version 1.1 of the configuration file. Most users will just want to write a file in the latest version and won't care about limitations of the older spec, especially since 1.0 never made it to a stable Fedora. Could we keep the 1.0 documentation in a separate page?

@evan-goode OK. I added commit that splits documentation to version specific files.

evan-goode · 2026-01-21T20:56:08Z

libdnf5/solv/vendor_change_manager.cpp

 void VendorChangeManager::load_vendor_change_policy(const std::filesystem::path & path) {
    VendorChangePolicy policy;

+    bool is_config_version_1_0;


Given the above, we may not even need to support 1.0 at all. We have a new major version with 5.4.0.0 after all. I'm fine either way.

I wanted to handle the configuration file extension properly, which is why I introduced version 1.1. Version 1.1 is backward compatible with 1.0 - meaning that if you change 1.0 to 1.1 in an old config file, it will work correctly in the new libdnf. However, I intentionally implemented checks in the new libdnf to disallow version 1.1 extensions when version 1.0 is specified. This was done so the user can be sure that if they test a version 1.0 config in the new libdnf, it will still work in older versions of libdnf that lack 1.1 support. It's simply a clean solution, though it’s a question of whether it’s strictly necessary. libdnf with version 1.0 support was released in Fedora Rawhide - but Rawhide is not a stable release.

It has been released into openSUSE Tumbleweed though, which is a stable rolling release. So it does matter.

libdnf5/solv/vendor_change_manager.cpp

evan-goode

LGTM otherwise. I tested manually, it works as expected. The docs are thorough and therefore long, but the large set of examples makes it easy enough to understand quickly. Thanks for making separate doc pages for 1.0 and 1.1.

CI tests with rpm-software-management/ci-dnf-stack#1817 are passing locally.

libdnf5/solv/vendor_change_manager.cpp

doc/dnf5.conf-vendorpolicy-v1_1.5.rst

doc/dnf5.conf-vendorpolicy.5.rst

- Allow "1.1" as a valid version string in configuration files. - Backward compatibility with "1.0" is maintained. - New version-specific extensions will be implemented in future commits. - Documentation updated.

Combining `equivalent_vendors` with `outgoing_vendors` or `incoming_vendors` was previously restricted to simplify configuration. However, this introduced an unnecessary rule. Since the underlying code supports this combination, the restriction is now enforced only for version "1.0" of the config file. Documentation updated.

Added a new method add_grow that allows adding an element by ID while ensuring sufficient memory capacity. The method takes an extra_capacity argument which defines the number of additional slots to allocate beyond the required minimum.

Defining only `incoming_vendors` without `outgoing_vendors` (and vice versa) was previously not supported. (`equivalent_vendors` is equivalent to defining both `incoming_vendors` and `outgoing_vendors` with the same content). However, in some cases, users want to allow a specific vendor to replace any installed vendor, or allow an installed vendor to be replaced by any other vendor. Previously, users had to define an explicit rule allowing "any" vendor. A nonexistent vendors array now implies "any vendor". Explicit rule for allowing any vendor are now required only for config version "1.0". Documentation updated. Example (any vendor can be replaced by 'My Trusted Vendor'): ```toml version = "1.0" [[outgoing_vendors]] vendor = '' comparator = 'CONTAINS' [[incoming_vendors]] vendor = 'My Trusted Vendor' ``` ```toml version = "1.1" [[incoming_vendors]] vendor = 'My Trusted Vendor' ```

It is better to catch regex errors early while parsing the config file, rather than allowing a failure to occur later during goal resolution.

Extend vendor change policy definitions to include 'outgoing_packages' and 'incoming_packages' filter lists. These lists restrict vendor changes only to packages that match the specified filters. If a list is omitted from the configuration file, no filtering is applied for that category (all packages are allowed). Documentation updated. Example 1: Allow installing packages from the command-line repo from any vendor: ``` version = '1.1' [[incoming_packages]] filters = [ { filter = 'cmdline_repo', value = 'true' } ] ``` Example 2: Allow installing packages from the command-line repo 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 3: Allow a change from any vendor to 'My Trusted Vendor', but only for incoming packages whose source package name is 'mypackage' and are located in the 'myrepo' repository: ``` version = '1.1' [[incoming_packages]] filters = [ { filter = 'source_name', value = 'mypackage' }, { filter = 'repoid', value = 'myrepo' } ] [[incoming_vendors]] vendor = 'My Trusted Vendor' ```

Add support for filtering packages by Epoch-Version-Release components using relational comparators (GT, GTE, LT, LTE, EXACT, NOT_EXACT). New filters use proper RPM version comparison instead of lexical string comparison, ensuring correct version ordering. String-based filters (name, source_name, arch, repoid) continue to use string comparators. Documentation updated. Example: 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' ```

Split the vendor change policy documentation from a single file into three separate files for better clarity and maintainability: - dnf5.conf-vendorpolicy.5.rst - Main file with basic information about vendor change policy configuration, TOML format, supported versions (1.0 and 1.1), and configuration file locations - dnf5.conf-vendorpolicy-v1_0.5.rst - Complete documentation for version 1.0 format, including file structure, vendor mapping definitions, error conditions, and examples - dnf5.conf-vendorpolicy-v1_1.5.rst - Complete documentation for version 1.1 format, including file structure, vendor mapping definitions, package filtering, error conditions, and examples Changes also include: - Enhanced vendor mapping definition explanations with clarifications about when vendor changes are allowed and how missing lists are interpreted - Added notes about configuration files requiring at least one supported list to have effect on vendor manager behavior

Error conditions are already clear from field descriptions, making these sections unnecessarily verbose.

jrohel requested a review from a team as a code owner January 20, 2026 17:26

jrohel requested review from evan-goode and removed request for a team January 20, 2026 17:26

jrohel force-pushed the vendor_change_policy1_1 branch from 4d31693 to 41a15f3 Compare January 20, 2026 17:34

jrohel added the work in progress label Jan 20, 2026

doc: VendorChangeManager: .conf extension, config files ordering

ede5c9c

jrohel force-pushed the vendor_change_policy1_1 branch from 41a15f3 to ac60e63 Compare January 20, 2026 18:56

jrohel removed the work in progress label Jan 20, 2026

jrohel mentioned this pull request Jan 20, 2026

Tests vendor change policies version "1.1" configured via TOML files rpm-software-management/ci-dnf-stack#1817

Open

evan-goode self-assigned this Jan 21, 2026

evan-goode reviewed Jan 21, 2026

View reviewed changes

jrohel force-pushed the vendor_change_policy1_1 branch from ac60e63 to 5b757bd Compare January 22, 2026 14:52

jrohel force-pushed the vendor_change_policy1_1 branch 2 times, most recently from 8751cc2 to ca8eebe Compare January 29, 2026 19:38

evan-goode reviewed Jan 29, 2026

View reviewed changes

libdnf5/solv/vendor_change_manager.cpp Outdated Show resolved Hide resolved

doc/dnf5.conf-vendorpolicy-v1_1.5.rst Outdated Show resolved Hide resolved

doc/dnf5.conf-vendorpolicy-v1_1.5.rst Show resolved Hide resolved

doc/dnf5.conf-vendorpolicy.5.rst Show resolved Hide resolved

jrohel added 7 commits February 1, 2026 17:41

VendorChangeManager: Accept version "1.1" in config files

5b6823f

- Allow "1.1" as a valid version string in configuration files. - Backward compatibility with "1.0" is maintained. - New version-specific extensions will be implemented in future commits. - Documentation updated.

Add "solv::SolvMap::add_grow" method

b110184

Added a new method add_grow that allows adding an element by ID while ensuring sufficient memory capacity. The method takes an extra_capacity argument which defines the number of additional slots to allocate beyond the required minimum.

VendorChangeManager: Validate vendor regex patterns during config load

ba93ee8

It is better to catch regex errors early while parsing the config file, rather than allowing a failure to occur later during goal resolution.

jrohel force-pushed the vendor_change_policy1_1 branch 2 times, most recently from 3f9a247 to b4ae68a Compare February 1, 2026 18:47

jrohel added 2 commits February 1, 2026 19:47

doc: Remove Error Conditions sections from vendor policy docs

b4ae68a

Error conditions are already clear from field descriptions, making these sections unnecessarily verbose.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

VendorChangeManager: Configuration version `1.1` with package-based filtering and enhanced flexibility #2579

VendorChangeManager: Configuration version `1.1` with package-based filtering and enhanced flexibility #2579

Uh oh!

jrohel commented Jan 20, 2026 •

edited

Loading

Uh oh!

evan-goode left a comment

Uh oh!

evan-goode Jan 21, 2026

Uh oh!

jrohel Jan 29, 2026 •

edited

Loading

Uh oh!

evan-goode Jan 21, 2026

Uh oh!

jrohel Jan 22, 2026

Uh oh!

Conan-Kudo Jan 22, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

evan-goode left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

VendorChangeManager: Configuration version 1.1 with package-based filtering and enhanced flexibility #2579

Are you sure you want to change the base?

VendorChangeManager: Configuration version 1.1 with package-based filtering and enhanced flexibility #2579

Uh oh!

Conversation

jrohel commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary of changes

1. Simplified vendor array rules

2. Package-based filtering (new feature)

3. Backward compatibility

4. Improved validation

5. Enhanced documentation

Examples

Uh oh!

evan-goode left a comment

Choose a reason for hiding this comment

Uh oh!

evan-goode Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

jrohel Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

evan-goode Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

jrohel Jan 22, 2026

Choose a reason for hiding this comment

Uh oh!

Conan-Kudo Jan 22, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

evan-goode left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

VendorChangeManager: Configuration version `1.1` with package-based filtering and enhanced flexibility #2579

VendorChangeManager: Configuration version `1.1` with package-based filtering and enhanced flexibility #2579

jrohel commented Jan 20, 2026 •

edited

Loading

jrohel Jan 29, 2026 •

edited

Loading