Skip to content

Change allow_vendor_change default to false with descriptive hint#2641

Open
fhbash wants to merge 1 commit intorpm-software-management:mainfrom
fhbash:allow-vendor-change
Open

Change allow_vendor_change default to false with descriptive hint#2641
fhbash wants to merge 1 commit intorpm-software-management:mainfrom
fhbash:allow-vendor-change

Conversation

@fhbash
Copy link
Copy Markdown
Contributor

@fhbash fhbash commented Mar 3, 2026

A previous attempt to change this default was reverted because solver errors gave no indication that vendor locking was the cause. The new hint in print_resolve_hints() addresses that by detecting RULE_UPDATE problems and telling the user how to override the restriction.

Closes: #712 #750 SWMBZBUGSM-153 BZ#2219624

CI Tests: rpm-software-management/ci-dnf-stack#1839

@fhbash fhbash requested a review from a team as a code owner March 3, 2026 19:17
@fhbash fhbash requested review from dcantrell and removed request for a team March 3, 2026 19:17
@Conan-Kudo
Copy link
Copy Markdown
Member

I think the descriptive hint essentially requires that we have a new top level CLI arg like I suggested (e.g --[no-]allow-vendor-change).

Additionally, are we not able to force vendor changes for packages individually with --from= or by using full NEVRAs?

- Change the default value of `allow_vendor_change` from `true` to `false` so packages stick to
their original vendor during upgrades (rpm-software-management#712)
- When the solver blocks an update due to a vendor change restriction, print a hint suggesting
`--setopt=allow_vendor_change=true` (rpm-software-management#750)

A previous attempt to change this default was reverted because solver errors gave no indication
that vendor locking was the cause. The new hint in `print_resolve_hints()` addresses that by
detecting `RULE_UPDATE` problems and telling the user how to override the restriction.

Closes: rpm-software-management#712 rpm-software-management#750 SWMBZBUGSM-153 BZ#2219624

CI Tests: rpm-software-management/ci-dnf-stack#1839

Signed-off-by: Fellipe Henrique <me@fhbash.com>
@fhbash fhbash force-pushed the allow-vendor-change branch from ac28ca3 to 20a3180 Compare March 12, 2026 18:34
@fhbash fhbash requested a review from evan-goode March 12, 2026 18:34
@fhbash
Copy link
Copy Markdown
Contributor Author

fhbash commented Mar 12, 2026

Removing from this PR the default value change... we'll keep the old state as it is.

@Conan-Kudo after discuss with the team, we decide to merge this PR without the default value change and the new CLI argument. We'll do an new PR for these changes for the next cicle (F45).

@evan-goode
Copy link
Copy Markdown
Member

To clarify, we think it's too close to F44 GA, and we'd like to submit a change proposal for F45 and have this spend some time in Rawhide.

@Conan-Kudo
Copy link
Copy Markdown
Member

Sure, makes sense to me. We should be able to get the CLI argument in before flipping the switch for F45 too, no?

@Conan-Kudo
Copy link
Copy Markdown
Member

That is, everything but flipping the default from True to False can be done for F44.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Use sticky vendors by default

3 participants