Bug 885646

Hi Miroslav,

thanks for the report. Am I reading it correctly that the package name has changed and the new package obsoletes the old one? In that case the observed behavior is fine: we can not decide for the user that a package that obsoletes another package is an upgrade (think situation where two packages obsolete each other: that would upgrade there and back on each 'dnf upgrade').

Yes, you are reading it correctly.

Obsoleting is normal upgrade process used by lots of packages in Fedora and happens very often. And is very well documented:
http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages

Yum handles it correctly. So from this POV it is regression.

If two packages obsoletes each other (without specifying version in obsolete) then it is bug in packaging and should be addressed by package maintainer. I'm not aware of such case in Fedora distribution.

(Internal note: could be achieved in libsolv with the right combo of SOLVER_FLAG_ALLOW_NAMECHANGE and SOLVER_FLAG_NO_UPDATEPROVIDE)

Nope, that should work as allow_namechange's default is "on". I bet it's a vendor change issue, you should set the SOLVER_FLAG_ALLOW_VENDORCHANGE option as Fedora doesn't do vendor locking and people aren't used to it.

Some comment about NO_UPDATEPROVIDE: if it is unset (the defaut), libsolv first checks for packages that have an obsoletes/provides combination when looking for update candidates. If it doesn't find any, it looks for obsoletes only. The idea is that you can have multiple obsoleters and can use the provides to define the one that is the "official" update.
If NO_UPDATEPROVIDE is set, libsolv will regard all obsoleting packages as update candidates.

About the circular obsoletes: libsolv actually handles that. If you have a cycle in the obsoletes, the cycle packages are handled as "equal", so it won't switch packages. It uses Tarjan's strongly connected components algorithm to find such cycles.

Thanks for your insight Michael.

I am still confused about the relationship between these two concrete packages (and unable to reproduce):

$ rpm -qp --obsoletes rhts-python-4.52-3.fc16.noarch.rpm 
$ rpm -qp --provides rhts-python-4.52-3.fc16.noarch.rpm 
rhts-python = 4.52-3.fc16
$

So that means the new package does not obsolete the old one? Also I haven't been able so far to track down the old package to see if it provides 'rhts-python'.

Maybe there's a conflict, try '-qp --conflicts'. But you're right, if there's no obsoletes the package is not considered newer. I don't think this is different from yum ;)

Still, you should set ALLOW_VENDORCHANGE ;)

rhts-devel-python-3.3-54.el5.noarch.rpm:
Provides 	
rhts-devel-python = 3.3-54.el5
rhts-python

Here's what I'm seeing for the old package:

$ rpm -qp --provides rhts-devel-python-3.3-54.el5.noarch.rpm 
rhts-python  
rhts-devel-python = 3.3-54.el5
$ rpm -qp --obsoletes rhts-devel-python-3.3-54.el5.noarch.rpm 
rhts-python  
$

conflicts are empty for both of them. It looks like rhts-devel-python is a supposed update for rhts-python, not the other way round.

Yeah, that's why 'dnf' deleted rhts-devel-python when it was asked to install rhts-python; the "obsoletes" acts like a conflict.

Note that if "allowuninstall" was off and the job was not a SOLVER_INSTALL_SOLVABLE job (or SOLVER_NOAUTOSET was used), the solver would have returned an error instead. See the "dnf sometimes downgrades" bug.

From .spec:
%package python
...
Obsoletes:  rhts-python
Provides:   rhts-python

Which is incorrect packaging, where package create circular depenency on itself.
Correct whay is to use obsolete and provides with version. But this package provides rhts-python and immediately obsolete it.

This is very common on thirdparty packages - I seen that a lot during package reviews in Fedora, where we of course fix that.

(rpm just ignores self-obsoletes, newer rpm versions even ignore self-conflicts. Packaging like this is not really a critical bug, but it conflicts with the packaging policy, because you can't go back to a newer rhts-python package later on. Thus obsoletes should always be versioned.

Anyway, it's not an upgrade, so this bug about dnf failing to upgrade can be closed, no?)

Hawkey commit e98ca20 sets the SOLVER_FLAG_ALLOW_VENDORCHANGE.

I am about to close this.

Ales,
I disagree with closing this bug (unless #13 is fix for this bug, but then the resolution is incorrect).

I am not saying what should be correct behaviour in this case. But it is definitelly different from yum. And if your goal is to replace yum one day, you should either behave the same as yum. Or change this to documentation bug and describe the deviation from yum.

So yum downgrades packages when I do 'yum upgrade'? The rhts-devel-python package is the newer package, so why should it be downgraded to rhts-python?

Or is the initial report wrong and the installed rhts-python is not upgraded to rhts-devel-python?

Ah, I read it once again. I did not mention yum in #0 and I just verified that it is not deviation from yum behaviour. So please ignore #14.
Everything is correct.

OK, all's fine:) I was about to try this with yum myself.