Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 885646 - Dnf fails to upgrade some packages
Summary: Dnf fails to upgrade some packages
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ales Kozumplik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-10 10:18 UTC by Miroslav Suchý
Modified: 2014-09-30 23:40 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-14 15:04:16 UTC
Type: Bug


Attachments (Terms of Use)

Description Miroslav Suchý 2012-12-10 10:18:39 UTC
Description of problem:
Dnf fails to upgrade some packages.

Version-Release number of selected component (if applicable):
dnf-0.2.15-3.git9c17a77.fc18.noarch

How reproducible:
done once

Steps to Reproduce:
1. install rhts-devel-python.noarch 3.3-54.el5
2. configure yum repo with new versions of rhts
3. dnf upgrade  # this offer me 146 packages to upgrade, but not rhts-devel
4. dnf install rhts-python
5. this will result in successful upgrade of rhts-devel-python to rhts-python

Installing:
 rhts-python                             noarch                       4.52-3.fc16                        beaker-client                        53 k
Removing:
 rhts-devel-python                       noarch                       3.3-54.el5                         @System                               0  

Expected results:
I would like to have this upgrade to have offered even during 'dnf upgrade'

If you do not know where is repos of rhts, ping me privately please.

Comment 1 Ales Kozumplik 2012-12-10 15:25:14 UTC
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').

Comment 2 Miroslav Suchý 2012-12-10 16:25:14 UTC
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.

Comment 3 Ales Kozumplik 2012-12-11 08:03:09 UTC
(Internal note: could be achieved in libsolv with the right combo of SOLVER_FLAG_ALLOW_NAMECHANGE and SOLVER_FLAG_NO_UPDATEPROVIDE)

Comment 4 Michael Schröder 2012-12-13 11:03:30 UTC
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.

Comment 5 Ales Kozumplik 2012-12-13 15:54:03 UTC
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'.

Comment 6 Michael Schröder 2012-12-13 16:21:42 UTC
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 ;)

Comment 8 Miroslav Suchý 2012-12-13 16:38:39 UTC
rhts-devel-python-3.3-54.el5.noarch.rpm:
Provides 	
rhts-devel-python = 3.3-54.el5
rhts-python

Comment 9 Ales Kozumplik 2012-12-13 16:42:59 UTC
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.

Comment 10 Michael Schröder 2012-12-13 16:54:43 UTC
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.

Comment 11 Miroslav Suchý 2012-12-13 17:06:57 UTC
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.

Comment 12 Michael Schröder 2012-12-13 17:24:04 UTC
(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?)

Comment 13 Ales Kozumplik 2012-12-13 17:31:01 UTC
Hawkey commit e98ca20 sets the SOLVER_FLAG_ALLOW_VENDORCHANGE.

I am about to close this.

Comment 14 Miroslav Suchý 2012-12-14 15:09:57 UTC
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.

Comment 15 Michael Schröder 2012-12-14 15:26:11 UTC
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?

Comment 16 Miroslav Suchý 2012-12-14 16:12:00 UTC
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.

Comment 17 Ales Kozumplik 2012-12-14 16:22:14 UTC
OK, all's fine:) I was about to try this with yum myself.


Note You need to log in before you can comment on or make changes to this bug.