I have prepared glibc update on COPR. Used dnf-3 to enable copr, since default dnf does not seem to be able to do that. But surprising is results differ on just common upgrade, when both versions seems to see the same version available. Reproducible: Always Steps to Reproduce: 1. dnf-3 copr enable -y pemensik/glibc 2. dnf5 upgrade glibc 3. dnf-3 upgrade glibc 4. Actual Results: # dnf5 upgrade glibc Updating and loading repositories: Repositories loaded. Nothing to do. # dnf-3 upgrade glibc Last metadata expiration check: 0:03:41 ago on Tue 04 Jul 2023 11:38:57 AM EDT. Dependencies resolved. ============================================================================================================================================ Package Architecture Version Repository Size ============================================================================================================================================ Upgrading: glibc x86_64 2.37.9000-15.1.fc39 copr:copr.fedorainfracloud.org:pemensik:glibc 2.2 M glibc-common x86_64 2.37.9000-15.1.fc39 copr:copr.fedorainfracloud.org:pemensik:glibc 337 k glibc-devel x86_64 2.37.9000-15.1.fc39 copr:copr.fedorainfracloud.org:pemensik:glibc 73 k glibc-gconv-extra x86_64 2.37.9000-15.1.fc39 copr:copr.fedorainfracloud.org:pemensik:glibc 1.6 M glibc-headers-x86 noarch 2.37.9000-15.1.fc39 copr:copr.fedorainfracloud.org:pemensik:glibc 485 k glibc-langpack-en x86_64 2.37.9000-15.1.fc39 copr:copr.fedorainfracloud.org:pemensik:glibc 593 k Transaction Summary ============================================================================================================================================ Upgrade 6 Packages Total download size: 5.2 M Is this ok [y/N]: Operation aborted. # dnf5 repolist repo id repo name beaker-client Beaker Client - Fedorarawhide beaker-harness Beaker harness copr:copr.fedorainfracloud.org:pemensik:glibc Copr repo for glibc owned by pemensik fedora-cisco-openh264 Fedora rawhide openh264 (From Cisco) - x86_64 rawhide Fedora - Rawhide - Developmental packages for the next Fedora release Expected Results: Both dnf5 and dnf-3 would offer me upgrade or none of them would. It is not that dnf5 does not see the update. It just ignores it for some reason. # dnf5 list glibc Updating and loading repositories: Repositories loaded. Installed packages glibc.x86_64 2.37.9000-15.fc39 rawhide Available packages glibc.i686 2.37.9000-15.fc39 rawhide glibc.src 2.37.9000-15.1.fc39 copr:copr.fedorainfracloud.org:pemensik:glibc glibc.x86_64 2.37.9000-15.1.fc39 copr:copr.fedorainfracloud.org:pemensik:glibc
I think this might be because of the switch of `allow_vendor_change` default configuration to false. https://dnf5.readthedocs.io/en/latest/changes.html#default-of-allow-vendor-change-configuration-option-changed-to-false Can you try with `--setopt=allow_vendor_change=true`?
Oh, so this is actually feature, not a bug. Yes, --setopt=allow_vendor_change=true helped. But I think especially if I run "dnf upgrade glibc", I would like to be notified it did not intentionally offered be available update. Could it print some warning mentioning a term to search in man or in documentation? I would certainly not find myself. Could it print something like: # dnf upgrade glibc Updating and loading repositories: Repositories loaded. Nothing to do. Warning: 1 vendor change prevented, consider allow_vendor_change=true Because this is something I was doing before, I would like some indication this is not a bug. How to continue if this is what I wanted. One line printed if there were some prevented changes should not be too much. It might have its own option, which could be turned off when this is known. For example --setopt=warn_vendor_change=true ?
# dnf upgrade glibc Updating and loading repositories: Repositories loaded. Nothing to do. # dnf upgrade glibc --setopt=allow_vendor_change=true Updating and loading repositories: Repositories loaded. Package Arch Version Repository Size Upgrading: glibc x86_64 2.37.9000-16.1.fc39 copr:copr.fedorainfracloud.org:pemensik 7.4 MiB replacing glibc x86_64 2.37.9000-16.fc39 rawhide 7.4 MiB glibc-common x86_64 2.37.9000-16.1.fc39 copr:copr.fedorainfracloud.org:pemensik 1.0 MiB replacing glibc-common x86_64 2.37.9000-16.fc39 rawhide 1.0 MiB glibc-devel x86_64 2.37.9000-16.1.fc39 copr:copr.fedorainfracloud.org:pemensik 37.1 KiB replacing glibc-devel x86_64 2.37.9000-16.fc39 rawhide 37.1 KiB glibc-gconv-extra x86_64 2.37.9000-16.1.fc39 copr:copr.fedorainfracloud.org:pemensik 7.8 MiB replacing glibc-gconv-extra x86_64 2.37.9000-16.fc39 rawhide 7.8 MiB glibc-headers-x86 noarch 2.37.9000-16.1.fc39 copr:copr.fedorainfracloud.org:pemensik 2.1 MiB replacing glibc-headers-x86 noarch 2.37.9000-16.fc39 rawhide 2.1 MiB glibc-langpack-en x86_64 2.37.9000-16.1.fc39 copr:copr.fedorainfracloud.org:pemensik 5.7 MiB replacing glibc-langpack-en x86_64 2.37.9000-16.fc39 rawhide 5.7 MiB Transaction Summary: Upgrading: 6 packages Replacing: 6 packages Total size of inbound packages is 5 MiB. Need to download 5 MiB. After this operation 455 B will be used (install 24 MiB, remove 24 MiB). Is this ok [y/N]: y ...
(In reply to Petr Menšík from comment #2) > Warning: 1 vendor change prevented, consider allow_vendor_change=true Yes "consider using --setopt=warn_vendor_change=true" > Because this is something I was doing before, I would like some indication > this is not a bug. How to continue if this is what I wanted. One line > printed if there were some prevented changes should not be too much. It > might have its own option, which could be turned off when this is known. Thank you for catching this - this was driving me crazy ;-)
(In reply to Jens Petersen from comment #4) > (In reply to Petr Menšík from comment #2) > > Warning: 1 vendor change prevented, consider allow_vendor_change=true > > Yes "consider using --setopt=warn_vendor_change=true" (ugh I meant '--setopt=allow_vendor_change=true')
*** Bug 2220861 has been marked as a duplicate of this bug. ***
*** Bug 2225014 has been marked as a duplicate of this bug. ***
The default has been reverted back: https://github.com/rpm-software-management/dnf5/pull/745 We would still like to have some message like this though in case the user configures allow_vendor_change=true manually and because in the future we would like to change the default permanently. It is tracked in upstream: https://github.com/rpm-software-management/dnf5/issues/750 and https://github.com/rpm-software-management/dnf5/issues/712
*** Bug 2225396 has been marked as a duplicate of this bug. ***
*** Bug 2226652 has been marked as a duplicate of this bug. ***
(In reply to amatej from comment #8) > The default has been reverted back: > https://github.com/rpm-software-management/dnf5/pull/745 Great news, thanks! It might okay to close this then, since you are also tracking it upstream.