F45 Change Proposal: Disable Vendor Change by Default (system-wide)

[amoloney (Aoife Moloney)]

Disable Vendor Change by Default

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

Summary

Change the default configuration of DNF5/libdnf5 by setting allow_vendor_change=False via the distribution defaults file /usr/share/dnf5/libdnf.conf.d/20-fedora-defaults.conf. This prevents libdnf5 from automatically replacing an installed package from one vendor with a package from another vendor during any transaction (such as upgrades, downgrades, or dependency resolution), unless explicitly requested by the user or allowed by VendorChangeManager rules.

Owner

• Name: Jaroslav Rohel, Fedora Release Engineering / Maintainers
• Email: jrohel@redhat.com, fedora-release-maintainers@fedoraproject.org

Detailed Description

By default, libdnf5 allows packages to switch vendors if a repository provides a different version or release of a package with a different VENDOR tag that satisfies a transaction. While this can sometimes resolve dependencies automatically, it can lead to unexpected behavior in multi-vendor setups (e.g., mixing packages between official Fedora Project, RPM Fusion, Copr, or third-party corporate repositories).

For instance, an essential multimedia package or a proprietary driver supplied by a specific vendor could be silently overwritten or downgraded by a package from another vendor during system updates or dependency resolution, potentially breaking user setups.

By introducing allow_vendor_change = false into Fedora’s default distribution configuration for DNF5, Fedora will achieve strict vendor isolation by default. A package will only be modified if the replacement package originates from the same vendor as the currently installed package, ensuring predictable behavior across all package operations.

Any intentional vendor transitions (such as stock Fedora packages being replaced by enhanced versions from RPM Fusion) will be handled either explicitly by the user via CLI configuration overrides or managed gracefully via VendorChangeManager rules defined in configuration drop-ins.

Feedback

Existing User Requests: There have been long-standing community requests and discussions regarding making vendor sticky behavior (in other words, disabling vendor changes by default) the standard configuration in Fedora.

Vendor Equivalence & Advanced Rules: During previous discussions, a common and critical requirement was the ability to define vendor equivalence classes or establish special transition rules for specific sets of vendors or packages. To address this, libdnf5 has been extended to support granular control over vendor sticky behavior out of the box through its newly designed VendorChangeManager architecture.

Allowing Vendor Change for Specific Packages: Community feedback emphasized that users must retain the flexibility to intentionally switch vendors for specific packages without globally disabling the vendor sticky protection. To support this use case, libdnf5 has been enhanced, and the DNF5 command-line interface now includes a dedicated --from-vendor= argument. This allows users to explicitly specify a set of permitted vendors for specific packages during a given transaction, ensuring safe and targeted package migrations.

Vendor Verification Override for Command-Line Packages: An edge case raised in discussions involved local package installations, where users requested that vendor restrictions be ignored for packages explicitly provided via a direct file system path. This requirement will be addressed as part of the scope of this change. A configuration file /usr/share/dnf5/vendors.d/allow-cmdline.conf will be shipped with the following content, leveraging the VendorChangeManager to automatically permit vendor changes for locally injected packages:

version = ‘1.1’ [[incoming_packages]] filters = [ { filter = ‘cmdline_repo’, value = ‘true’ } ]

Benefit to Fedora

• System Stability: Reduces the risk of accidental vendor swaps across all package operations (upgrades, downgrades, and dependency resolution).

• Granular Control: Leverages DNF5’s advanced architecture (VendorChangeManager) to allow explicit, trusted vendor transitions while keeping the general system safe from accidental overwrites.

Scope

• Proposal owners:
  • Add allow_vendor_change=False to /usr/share/dnf5/libdnf.conf.d/20-fedora-defaults.conf in the fedora-release-common package.
  • Ship a new /usr/share/dnf5/vendors.d/allow-cmdline.conf in the fedora-release-common package, with the following content:

version = ‘1.1’ [[incoming_packages]] filters = [ { filter = ‘cmdline_repo’, value = ‘true’ } ]

• Other developers:

N/A. This change is confined to the fedora-release-common package. No changes to packaging guidelines, RPM spec files, or build processes are required from other package maintainers.

• Release engineering: #13394

• Policies and guidelines: N/A (not needed for this Change)

• Trademark approval: N/A (not needed for this Change)

• Alignment with the Fedora Strategy:

This proposal does not directly target any specific Fedora Strategy 2028 theme, but it improves the reliability of the package management foundation on which all Fedora variants build.

Upgrade/compatibility impact

• Existing installations upgrading to Fedora 45: Will automatically inherit this safety feature via the updated dnf5 defaults, unless the user has explicitly overridden allow_vendor_change = true – e.g. in system configuration files in /etc/dnf/libdnf5.conf.d/ drop-in directory or /etc/dnf/dnf.conf.

• User intervention for intentional changes: If a user explicitly wants to switch a package to a different VENDOR (and no VendorChangeManager rule applies), they will need to use the --from-vendor=VENDOR or --setopt=allow_vendor_change=1 (which completely disables vendor change control for all packages, not just for the package listed in the command line) for that specific transaction.

Early Testing (Optional)

Do you require ‘QA Blueprint’ support? No

How To Test

Test Scenario A: Preventing unwanted vendor change via Upgrade

1. Install a PACKAGE with a specific VENDOR tag (e.g., from a Copr repository).
2. Enable another repository containing the same package name with a higher version/release but with a different VENDOR tag, ensuring no VendorChangeManager rule allows a transition between these two specific vendors.
3. Run dnf5 upgrade PACKAGE.
4. Expected result: DNF5 should not replace the package with the one from the new vendor. It should keep the current package and either skip the update or fail with a dependency conflict.
5. Verification of override: Running dnf5 --setopt=allow_vendor_change=1 upgrade PACKAGE should successfully allow the transaction and change the vendor.

Test Scenario B: Preventing unwanted vendor change via Downgrade

1. Install a PACKAGE with a specific VENDOR tag (e.g., from a Copr repository).
2. Enable another repository containing the same package name with a lower version/release but with a different VENDOR tag, ensuring no VendorChangeManager rule allows a transition between these two specific vendors.
3. Run dnf5 downgrade PACKAGE.
4. Expected result: DNF5 should not swap the package vendor to perform the downgrade. It should refuse the transaction or fail with a dependency conflict.
5. Verification of override: Running dnf5 --setopt=allow_vendor_change=1 downgrade PACKAGE should successfully allow the transaction and change the vendor.

User Experience

• Users with only official Fedora repositories: No noticeable change. Packages should originate from the same vendor, so no vendor change conflicts should arise during updates.

• Users with packages from multiple sources (RPM Fusion, Copr, corporate repositories, etc.): DNF5 will no longer silently replace a package installed from one source with a version from a different source. If a system update or dependency resolution would result in such a replacement, DNF5 will decline the transaction and inform the user about the conflict, instead of making the change without notice.

• Installing a local RPM file: Installing a package directly from a file (e.g. dnf5 install ./package.rpm) will continue to work as before, without requiring any additional options.

• Intentional vendor switch: Users who deliberately want to replace a package with a version from a different source can use the new --from-vendor=VENDOR option to allow that specific switch for the duration of the transaction.

Dependencies

This change requires that libdnf5 with full VendorChangeManager support, the allow_vendor_change configuration option, and the --from-vendor= CLI argument is available in Fedora 45. This requirement is already satisfied: the necessary libdnf5 version is available in Fedora 44 updates and will be present in Fedora 45.

Contingency Plan

• Contingency mechanism: Revert the shipped configuration.
• Contingency deadline: the beta freeze.
• Blocks release? No.

Documentation

• The allow_vendor_change configuration option is documented in the DNF5 Configuration Reference.
• The VendorChangeManager rule file format (used for the /usr/share/dnf5/vendors.d/ drop-in directory) is documented in the DNF5 Vendor Change Policy File Reference - v1.1.
• The --from-vendor= CLI argument is documented per individual command, for example in the Install Command reference.

Release Notes

Starting with Fedora Linux 45, DNF5/libdnf5 no longer automatically replaces an installed package with a version from a different vendor during updates, downgrades, or dependency resolution. If you have packages from third-party repositories (such as RPM Fusion, Copr, or corporate repositories), DNF5/libdnf5 will refuse transactions that would silently switch those packages to a different vendor and will notify you of the conflict instead.

To allow a vendor change for specific packages in a given transaction, use the --from-vendor=VENDOR option. To disable this protection entirely for a single transaction, use --setopt=allow_vendor_change=1. To restore the previous behavior permanently, set allow_vendor_change = true in a drop-in configuration file under /etc/dnf/libdnf5.conf.d/.

Last edited by @amoloney 2026-06-30T17:01:11Z

Last edited by @amoloney 2026-06-30T17:01:11Z

[system]

How do you feel about the proposal as written?

• Strongly in favor
• In favor, with reservations
• Neutral
• Opposed, but could be convinced
• Strongly opposed

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

[msuchy (Miroslav Suchý)]

I would love to see a documented:

• How do I find that there is a newer package from a different vendor? I, personally, would prefer if DNF notifies me on each run of ‘dnf upgrade’ about it.
• How do I find the VENDOR string (for installed package and for package in remote repo)? It is obvious to me, but it can be less obvious to a regular user.
• Specific examples of how I upgraded to a different vendor. We have Swap Command — dnf5 documentation and documentation of --from-vendor but I would love to have more explicit documentation in HOWTO form.

[jrohel (Jaroslav Rohel)]

Thank you for your feedback.

I, personally, would prefer if DNF notifies me on each run of ‘dnf upgrade’ about it.

We’ve been discussing adding a notification for this scenario within the dnf team. We are currently weighing two different approaches:

• Option A: Display only a generic warning/message stating that there are upgrades available, but they are from a different vendor (and thus skipped due to vendor locking).
• Option B: Display a list of the specific package names that have newer versions available from a different vendor and are skipped due to vendor locking.

While Option B is arguably more informative, a long list could become quite noisy and annoying for users during every routine command (upgrade, downgrade, etc.). Finding the right balance between being informative and staying out of the user’s way is our main focus right now.

How to find the VENDOR string

For an installed package:
Using DNF:
dnf repoquery --installed <package> --queryformat '%{vendor}\n'
dnf repoquery --installed <package> --qf '%{vendor}\n'

Using RPM:
rpm -q <package> --qf '%{vendor}\n'

For a package in a remote repository: Simply drop the --installed filter from the DNF query.

Although --queryformat is documented in the dnf5-repoquery man pages, we can look into ways to emphasize it more.

Specific examples of how I upgraded to a different vendor.

Good point. More examples in the documentation may be helpful.

[jrohel (Jaroslav Rohel)]

@vgaetera

All distro configs should have a numeric prefix, here’s an example:
rpms/fedora-release/20-fedora-defaults.conf - src.fedoraproject.org
Otherwise it’s problematic to override, e.g. if someone wants to not allow exceptions for local package installations.

That shouldn’t be an issue because of how DNF5 handles vendor policy evaluation and configuration priority.

First, vendor policy configuration files are indeed sorted alphanumerically and processed in that order, but the sequence does not affects the final outcome. The logic acts as a whitelist - once a rule matches and allows a vendor change for a given package, it is applied. Therefore, a numeric prefix for vendor change rules doesn’t change the behavior.

Second, to override a specific distribution vendor policy (stored in /usr/share/dnf5/vendors.d/), the standard mechanism is to simply create a file with the exact same name in /etc/dnf/vendors.d/.

As stated in the official DNF5 documentation (DNF5 Vendor Change Policy File Reference — dnf5 documentation):

“If a file with the same name exists in both directories, the file from /etc/dnf/vendors.d/ is used. This implies that the distribution configuration file can be simply overridden by creating a file with the same name in the /etc/dnf/vendors.d/ directory.”

To effectively disable exceptions for local installations, the override file in /etc/dnf/vendors.d/ can even be empty, containing only the mandatory version line (e.g., version = '1.1').

[ngompa (Neal Gompa)]

@amoloney

1. Verification of override: Running dnf5 --setopt=allow_vendor_change=1 upgrade PACKAGE should successfully allow the transaction and change the vendor.

I’m not really a fan of telling people to use --setopt= for expected workflows, so I’ve submitted a pull request to add a proper top-level --[no-]allow-vendor-change option.

[gtb (Gary Buhrmaster)]

The proposal states that using local rpms will continue to work as before. I need some better understanding about that use case.

I sometimes have a need (desire) to move to the next full releases version, and use fedpkg --release mockbuild to build the rawhide version in the release. I then install it locally. I expect it to be upgraded automatically when I eventually upgrade the entire distro to that next release.

Since the vendor is now “(none)”, will the upgrade to the next release version happen correctly for this local rpm?

[ngompa (Neal Gompa)]

@gtb

Since the vendor is now “(none)”, will the upgrade to the next release version happen correctly for this local rpm?

Yes. That is the expected outcome.

[xvitaly]

It looks like the authors of the proposal are ignoring the mailing list, so I’ll copy and paste my message here.

1. If a user has enabled a third-party COPR repository, then after this change they won’t be able to automatically install packages from it via a simple sudo dnf copr enable ... && sudo dnf upgrade --refresh command, right?
2. What happens if a user installs a package from a third-party COPR repository, and then a new version appears in the official Fedora repository? Will they be permanently locked to this unsupported version, or what?

[jrohel (Jaroslav Rohel)]

1. If a user has enabled a third-party COPR repository, then after this change they won’t be able to automatically install packages from it

   • They will be able to install packages from it.

   via a simple sudo dnf copr enable ... && sudo dnf upgrade --refresh command, right?

   • You are talking about upgrading already installed packages from another vendor. In that case, it is a vendor change for an installed package, which is exactly what will no longer be allowed by default.

2. What happens if a user installs a package from a third-party COPR repository, and then a new version appears in the official Fedora repository? Will they be permanently locked to this unsupported version, or what?

   • Yes, exactly. Imagine this scenario: you intentionally install packages (such as a special version with different patches or configuration) from another vendor, usually a third-party repository. Then, a newer version of these packages appears from the Fedora Project vendor. The goal of this change is to prevent an automatic, unwanted package vendor change. I understand your point of view, but libdnf cannot arbitrarily allow such a change.

On the other hand, libdnf includes a configurable vendor change policy manager. See the documentation at DNF5 Vendor Change Policy File Reference - v1.1 — dnf5 documentation

• Example of a configuration that ensures packages whose vendor name starts with “Fedora Copr” will be interchangeable with packages whose vendor is “Fedora Project”. This allows bidirectional vendor changes between the official “Fedora Project” vendor and vendors starting with “Fedora Copr”:

version = '1.1'

[[equivalent_vendors]]
vendor = 'Fedora Project'
comparator = 'EXACT'

[[equivalent_vendors]]
vendor = 'Fedora Copr'
comparator = 'STARTSWITH'

An even more interesting configuration example: if a user installs a package from a “Fedora Copr” vendor, the system will keep them locked to it only until a higher version appears from the “Fedora Project” vendor. However, once the package upgrades to the official one, this second configuration example does not allow switching back to “Fedora Copr” again:

version = '1.1'

[[incoming_vendors]]
vendor = 'Fedora Project'
comparator = 'EXACT'

[[outgoing_vendors]]
vendor = 'Fedora Copr'
comparator = 'STARTSWITH'

Therefore, the libdnf5 vendor change policy manager is highly flexible. However, users have varying requirements, making it somewhat difficult to choose the best default configuration. What is certain is that there is a demand to move away from the current state where vendor changes for installed packages are globally permitted. That is why I wrote this “Disable Vendor Change by Default” proposal.