Wiki - https://fedoraproject.org/wiki/Changes/DisableVendorChangeByDefault
Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-disable-vendor-change-by-default-system-wide/195269


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.

== Summary ==
Change the default configuration of '''DNF5/libdnf5''' by setting
<code>allow_vendor_change=False</code> via the distribution defaults
file <code>/usr/share/dnf5/libdnf.conf.d/20-fedora-defaults.conf</code>.
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: [[User:jrohel| Jaroslav Rohel]],
[[Subprojects/ReleaseEngineering|Fedora Release Engineering /
Maintainers]]
* Email: <[email protected]>, <[email protected]>



== 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 <code>VENDOR</code> 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 <code>allow_vendor_change = false</code> 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 <code>--from-vendor=</code> 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
<code>/usr/share/dnf5/vendors.d/allow-cmdline.conf</code> will be
shipped with the following content, leveraging the
''VendorChangeManager'' to automatically permit vendor changes for
locally injected packages:
<pre>
version = '1.1'

[[incoming_packages]]
filters = [
  { filter = 'cmdline_repo', value = 'true' }
]
</pre>


== 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 <code>allow_vendor_change=False</code> to
<code>/usr/share/dnf5/libdnf.conf.d/20-fedora-defaults.conf</code> in
the <code>fedora-release-common</code> package.
** Ship a new <code>/usr/share/dnf5/vendors.d/allow-cmdline.conf</code>
in the <code>fedora-release-common</code> package, with the following
content:
<pre>
version = '1.1'

[[incoming_packages]]
filters = [
  { filter = 'cmdline_repo', value = 'true' }
]
</pre>

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

* Release engineering:
[https://forge.fedoraproject.org/releng/tickets/issues/13394 #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
<code>allow_vendor_change = true</code> – e.g. in system configuration
files in <code>/etc/dnf/libdnf5.conf.d/</code> drop-in directory or
<code>/etc/dnf/dnf.conf</code>.

* '''User intervention for intentional changes:''' If a user
explicitly wants to switch a package to a different
<code>VENDOR</code> (and no ''VendorChangeManager'' rule applies),
they will need to use the <code>--from-vendor=VENDOR</code> or
<code>--setopt=allow_vendor_change=1</code> (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 ===

# Install a <code>PACKAGE</code> with a specific <code>VENDOR</code>
tag (e.g., from a Copr repository).
# Enable another repository containing the same package name with a
higher version/release but with a different <code>VENDOR</code> tag,
ensuring no ''VendorChangeManager'' rule allows a transition between
these two specific vendors.
# Run <code>dnf5 upgrade PACKAGE</code>.
# '''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.
# '''Verification of override:''' Running <code>dnf5
--setopt=allow_vendor_change=1 upgrade PACKAGE</code> should
successfully allow the transaction and change the vendor.

=== Test Scenario B: Preventing unwanted vendor change via Downgrade ===

# Install a <code>PACKAGE</code> with a specific <code>VENDOR</code>
tag (e.g., from a Copr repository).
# Enable another repository containing the same package name with a
lower version/release but with a different <code>VENDOR</code> tag,
ensuring no ''VendorChangeManager'' rule allows a transition between
these two specific vendors.
# Run <code>dnf5 downgrade PACKAGE</code>.
# '''Expected result:''' DNF5 should not swap the package vendor to
perform the downgrade. It should refuse the transaction or fail with a
dependency conflict.
# '''Verification of override:''' Running <code>dnf5
--setopt=allow_vendor_change=1 downgrade PACKAGE</code> 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. <code>dnf5 install ./package.rpm</code>) 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 <code>--from-vendor=VENDOR</code> option to allow that specific
switch for the duration of the transaction.


== Dependencies ==
This change requires that ''libdnf5'' with full
''VendorChangeManager'' support, the <code>allow_vendor_change</code>
configuration option, and the <code>--from-vendor=</code> 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 <code>allow_vendor_change</code> configuration option is
documented in the
[https://dnf5.readthedocs.io/en/latest/dnf5.conf.5.html DNF5
Configuration Reference].
* The ''VendorChangeManager'' rule file format (used for the
<code>/usr/share/dnf5/vendors.d/</code> drop-in directory) is
documented in the
[https://dnf5.readthedocs.io/en/latest/dnf5.conf-vendorpolicy-v1_1.5.html
DNF5 Vendor Change Policy File Reference - v1.1].
* The <code>--from-vendor=</code> CLI argument is documented per
individual command, for example in the
[https://dnf5.readthedocs.io/en/latest/commands/install.8.html 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 <code>--from-vendor=VENDOR</code> option. To disable this
protection entirely for a single transaction, use
<code>--setopt=allow_vendor_change=1</code>. To restore the previous
behavior permanently, set <code>allow_vendor_change = true</code> in a
drop-in configuration file under
<code>/etc/dnf/libdnf5.conf.d/</code>.


-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney

-- 
_______________________________________________
devel-announce mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: 
https://forge.fedoraproject.org/infra/tickets/issues/new
-- 
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: 
https://forge.fedoraproject.org/infra/tickets/issues/new

Reply via email to