dnf update local file doesn't work as expected

[rwmjones]

I have this installed now:

libisofs-1.5.6-1.fc38.x86_64
dnf5-5.0.15-3.fc39.x86_64

and I built a local update for libisofs, but it cannot be updated and the messages are weird:

$ sudo dnf update $PWD/x86_64/libisofs-1.5.6-2.fc39.x86_64.rpm 
Updating and loading repositories:
Repositories loaded.
Nothing to do.

$ sudo dnf update $PWD/x86_64/libisofs-1.5.6-2.fc39.x86_64.rpm --best
Updating and loading repositories:
Repositories loaded.
Nothing to do.

$ sudo dnf install $PWD/x86_64/libisofs-1.5.6-2.fc39.x86_64.rpm --best
Updating and loading repositories:
Repositories loaded.
Failed to resolve the transaction:
Problem: problem with installed package 
  - cannot install both libisofs-1.5.6-1.fc38.x86_64 and libisofs-1.5.6-2.fc39.x86_64
  - cannot install both libisofs-1.5.4-5.fc38.x86_64 and libisofs-1.5.6-2.fc39.x86_64
  - conflicting requests

I suspect this is caused because the new package has impossible to satisfy dependencies, but it should say that (if that's the case).

[rwmjones]

Actually my last paragraph is not correct. The new package was installable using rpm directly:

$ sudo rpm -Uvh $PWD/x86_64/libisofs-1.5.6-2.fc39.x86_64.rpm 
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
Updating / installing...
   1:libisofs-1.5.6-2.fc39            ################################# [ 50%]
Cleaning up / removing...
   2:libisofs-1.5.6-1.fc38            ################################# [100%]

So I think dnf is wrong here.

[rwmjones]

Also downgrading doesn't work, with equally weird message:

$ sudo dnf downgrade libisofs --releasever=39 
Updating and loading repositories:
Repositories loaded.
Failed to resolve the transaction:
Problem: cannot install both libisofs-1.5.6-1.fc39.x86_64 and libisofs-1.5.6-2.fc39.x86_64
  - cannot install the best candidate for the job
  - problem with installed package 

(even --nobest doesn't work)

[jan-kolarik]

Hi, it seems as an another consequence of the change of allow_vendor_change option default value to False (PR origin). Could you please try with the --setopt=allow_vendor_change=true?

[rwmjones]

Yes it works if I add that. I don't understand what the allow_vendor_change option is meant for. Why prevent a command I have explicitly typed, with not even a message about what I need to do to fix it?

[jan-kolarik]

There are situations where you want to keep installing updates for a given installed package only from the same provider it was installed from. Setting this option to true allows you f.e. to upgrade a package installed from official Fedora repository with a package from a COPR which is sometimes unwanted as there are usually rather unstable packages provided.

But anyway, you are right that user should be provided with some useful explanation, although this is hard for dnf as the decision is made by the 3rd party component - the solver. We will definitely discuss this issue on our following team meeting.

[Conan-Kudo]

We could always ignore sticky vendors when you're installing a local package, as that's effectively equivalent to requesting an explicit package (which should be always allowed).

FWIW, Zypper does it this way too, so it would be consistent handling of this capability.

[keszybz]

I'm seeing this too when trying to install rpms built in mock. With --setopt=allow_vendor_change=true it works.

[j-mracek]

For vendor change implementation we could loot at zipper. There is a related bugzilla on DNF - Bug 1890505 - [RFE] Configuration for equivalent vendors for "vendor stickiness"

[Conan-Kudo]

Oh that would be great to have implemented!