Bug 1211991 - PackageKit fails to install obsoleting pakcages
Summary: PackageKit fails to install obsoleting pakcages
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F22BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2015-04-15 11:21 UTC by Petr Schindler
Modified: 2015-04-17 02:30 UTC (History)
11 users (show)

Fixed In Version: libhif-0.1.8-8.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-17 02:30:31 UTC


Attachments (Terms of Use)
journalctl of boot with affected update (375.18 KB, text/x-vhdl)
2015-04-15 11:21 UTC, Petr Schindler
no flags Details

Description Petr Schindler 2015-04-15 11:21:00 UTC
Created attachment 1014686 [details]
journalctl of boot with affected update

Description of problem:
An offline-update failed to update libphodav-2.0-1.fc22.x86_64 which is obsoleting libphodav-1.0-0.4-5.fc22.x86_64. When this happens no update is installed. So it basicly blocks offline updates when there is some obsoleting update.

Offline updates worked fine after I updated libphodav (the only obsoleting package in that update) with dnf and then performed offline update.

output from journalctl with update information:
pk-offline-update[867]: percentage 9%
pk-offline-update[867]: percentage 10%
pk-offline-update[867]: percentage 14%
pk-offline-update[867]: sent msg to plymouth 'Installing Updates - 14%'
pk-offline-update[867]: status request
pk-offline-update[867]: percentage 15%
pk-offline-update[867]: sent msg to plymouth 'Installing Updates - 15%'
pk-offline-update[867]: percentage 17%
pk-offline-update[867]: sent msg to plymouth 'Installing Updates - 17%'
pk-offline-update[867]: status test-commit
pk-offline-update[867]: status finished
PackageKit[878]: update-packages transaction /6_dccdacdc from uid 0 finished with failed after 5282ms
pk-offline-update[867]: writing failed results
pk-offline-update[867]: failed to update system: Error running transaction: package libphodav-2.0-1.fc22.x86_64 is obsoleted by libphodav-2.0-1.fc22.x86_64
pk-offline-update[867]: rebooting
pk-offline-update[867]: sent mode to plymouth 'shutdown'
pk-offline-update[867]: sent msg to plymouth 'Rebooting after installing updates…'

part of dnf history info last:
Obsoleting libphodav-2.0-1.fc22.x86_64     @updates-testing
Install    libphodav-2.0-1.fc22.x86_64     @updates-testing
Obsoleted  libphodav-1.0-0.4-5.fc22.x86_64 (unknown)

Version-Release number of selected component (if applicable):
PackageKit-1.0.6-1.fc22.x86_64

How reproducible:
always when updating obsoleting package

Additional info:
I propose this as beta blocker because it violates beta criterion: "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops."

But I vote -1 for Beta blocker +1 Final blocker because other updates work fine. Just small amount of updates will be affected and I don't think it is worth of blocking beta for this problem.

Comment 1 Richard Hughes 2015-04-15 13:26:06 UTC
I'm really confused why libphodav obsoletes itself.

Comment 2 Kamil Páral 2015-04-15 13:38:59 UTC
I can reproduce this easily. Just install F22 Beta RC2 Workstation and force and offline update. It fails with the error message above.

(In reply to Petr Schindler from comment #0)
> But I vote -1 for Beta blocker +1 Final blocker because other updates work
> fine. Just small amount of updates will be affected and I don't think it is
> worth of blocking beta for this problem.

Petr wanted to say here that this will rarely happen. But unfortunately, it happened for Beta RC2. libphodav-1.0-0.4-5.fc22.x86_64 is baked into that image. And it means that users won't be available to update *at all*, unless packagekit is fixed *on the media* or libphodav-2.0-1.fc22.x86_64 is unpushed. So this seems to be an direct criterion violation.

Note:

F22 stable:          libphodav-0.4-5.fc22
Beta RC2:            libphodav-1.0-0.4-5.fc22
F22 updates-testing: libphodav-2.0-1.fc22

Two things - RC2 contains a non-stable package for some reason, and it's *name* is different (libphodav-1.0 is the name, 0.4 is the version). I guess that's why they obsolete it, because it happened to be a typo (version part of the name)?

Comment 3 Rex Dieter 2015-04-15 13:40:56 UTC
It isn't Obsolete'ing itself here, though that is sometimes a valid use-case for changing subpackages.

The case here, is the package *names* being Obsoletes:'d were libphodav-1.0 and libphodav-2.0 (arguably bad, and probably should have been caught during initial review).  In particular, the Obsoletes in question are:

Obsoletes:      libphodav-2.0 <= 0:2.0-3
Obsoletes:      libphodav2 <= 0:2.0-4
# no Provides for this one as ABI was broken
Obsoletes:      libphodav-1.0 <= 0:0.4-6

See also bug #1195913 on a little of the related history.

Comment 4 Kalev Lember 2015-04-15 14:38:24 UTC
I think the update error can be worked around for now by fixing the Obsoletes in libphodav, so that it doesn't do self-obsoletes. This should hopefully make the packagekit offline updates work properly post-beta.

Something like (untested):

Obsoletes:      libphodav2 <= 0:2.0-4
==>
Obsoletes:      libphodav2 < 0:2.0-4

But for the final release, I think the packagekit offline updates needs a bit of love to make sure it properly handles obsoletes. From my poking around in the code today, this isn't entirely trivial, and I'd rather fix this post-beta where we have time to properly test the changes.

Comment 5 Adam Williamson 2015-04-15 14:58:39 UTC
Kalev: well, that paste is from the master branch. So far as I can see, the F22 branch has only:

%package -n     libphodav
Obsoletes:      libphodav-1.0 <= 0:0.4-6

%package -n     libphodav-devel
Obsoletes:      libphodav-1.0-devel <= 0:0.4-6

Those are the only two Obsoletes: lines in the spec. So, not sure what's going on, but it seems weird.

Comment 6 Adam Williamson 2015-04-15 15:49:33 UTC
So still don't know what's going on here, but some more info:

22 Beta RC2 Workstation live has only one phodav-related package installed: libphodav-1.0-0.4-5.fc22.

Note that this is *not* a 'non-stable package' as #c2 suggests. It is not version 1.0-0.4-5 of the package 'libphodav', but version 0.4-5 of the package 'libphodav-1.0', which is a sub-package of 'phodav': that is, it comes from the source package phodav-0.4-5.fc22, which is the current stable version.

It is installed because spice-glib-0.27-5.fc22 and spice-gtk3-0.27-5.fc22 require it:

[root@localhost liveuser]# rpm -q --requires spice-glib spice-gtk3 | grep pho
libphodav-1.0.so.0()(64bit)
libphodav-1.0.so.0(LIBPHODAV1_0.0)(64bit)
libphodav-1.0.so.0()(64bit)
[root@localhost liveuser]# rpm -q --whatprovides "libphodav-1.0.so.0()(64bit)"
libphodav-1.0-0.4-5.fc22.x86_64
[root@localhost liveuser]# rpm -q --whatprovides "libphodav-1.0.so.0(LIBPHODAV1_0.0)(64bit)"
libphodav-1.0-0.4-5.fc22.x86_64

When you try and do an update, I believe the trigger for the issue is that spice-glib and spice-gtk3 get updated. The relevant update is:

https://admin.fedoraproject.org/updates/FEDORA-2015-5433/phodav-2.0-1.fc22,spice-gtk-0.28-2.fc22

Note that the package libphodav-2.0-1.fc22 is *not* directly an update for the package libphodav-1.0-0.4-5.fc22. Instead, it's the dependencies of the spice-gtk subpackages that change (this paste is from my desktop, which has already done the update with dnf):

[adamw@adam tmp]$ rpm -q spice-gtk3 spice-glib
spice-gtk3-0.28-2.fc22.x86_64
spice-glib-0.28-2.fc22.x86_64
[adamw@adam tmp]$ rpm -q --requires spice-gtk3 | grep pho
libphodav-2.0.so.0()(64bit)
[adamw@adam tmp]$ rpm -q --requires spice-glib | grep pho
libphodav-2.0.so.0()(64bit)
libphodav-2.0.so.0(LIBPHODAV1_0.0)(64bit)
[adamw@adam tmp]$ rpm -q --whatprovides "libphodav-2.0.so.0()(64bit)"
libphodav-2.0-1.fc22.x86_64
[adamw@adam tmp]$ rpm -q --whatprovides "libphodav-2.0.so.0(LIBPHODAV1_0.0)(64bit)"
libphodav-2.0-1.fc22.x86_64

So the update should have libphodav-2.0-1.fc22 added to it to satisfy the dependencies of spice-gtk3 and spice-glib.

As for the obsoletes, the spec file, koji, and rpm all agree that libphodav-2.0-1.fc22 obsoletes only one thing:

[adamw@adam tmp]$ rpm -qp --obsoletes libphodav-2.0-1.fc22.x86_64.rpm 
libphodav-1.0 <= 0:0.4-6

So it is reasonable that the update transaction should install libphodav-2.0-1.fc22 and remove (as obsoleted, and no longer required by anything) libphodav-1.0-0.4-5.fc22 .

I cannot find anything funky or overlapping in the Provides or Obsoletes of the two libphodav(-1.0) packages. libphodav-2.0-1.fc22 doesn't provide the thing it's obsoleting, libphodav-1.0 does not provide anything libphodav-2.0-1.fc22 provides, nothing like that. All the metadata looks pretty clean.

I cannot find anything other than libphodav-2.0-1.fc22 from http://koji.fedoraproject.org/koji/buildinfo?buildID=625644 which has the apparent name 'libphodav-2.0-1.fc22' or would otherwise be involved in this; I wondered for a bit if we had a rogue 'libphodav-2.0' package lying around somewhere, but I can't find such a thing in F22. The 22 'stable' repo has phodav 0.4-5 in it, the 'updates-testing' remove has phodav 2.0-1.fc22 in it, that's all.

[adamw@adam tmp]$ rpm -qp --obsoletes libphodav-2.0-1.fc22.x86_64.rpm 
libphodav-1.0 <= 0:0.4-6
[adamw@adam tmp]$ rpm -qp --provides libphodav-1.0-0.4-5.fc22.x86_64.rpm 
libphodav-1.0 = 0.4-5.fc22
libphodav-1.0(x86-64) = 0.4-5.fc22
libphodav-1.0.so.0()(64bit)
libphodav-1.0.so.0(LIBPHODAV1_0.0)(64bit)
[adamw@adam tmp]$ rpm -qp --obsoletes libphodav-1.0-0.4-5.fc22.x86_64.rpm
[adamw@adam tmp]$ rpm -qp --requires libphodav-1.0-0.4-5.fc22.x86_64.rpm
/sbin/ldconfig
/sbin/ldconfig
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libgio-2.0.so.0()(64bit)
libglib-2.0.so.0()(64bit)
libgobject-2.0.so.0()(64bit)
libpthread.so.0()(64bit)
libsoup-2.4.so.1()(64bit)
libxml2.so.2()(64bit)
libxml2.so.2(LIBXML2_2.4.30)(64bit)
libxml2.so.2(LIBXML2_2.6.0)(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) <= 5.2-1
[adamw@adam tmp]$ rpm -qp --provides libphodav-2.0-1.fc22.x86_64.rpm 
libphodav = 2.0-1.fc22
libphodav(x86-64) = 2.0-1.fc22
libphodav-2.0.so.0()(64bit)
libphodav-2.0.so.0(LIBPHODAV1_0.0)(64bit)
[adamw@adam tmp]$ rpm -qp --obsoletes libphodav-2.0-1.fc22.x86_64.rpm 
libphodav-1.0 <= 0:0.4-6
[adamw@adam tmp]$ rpm -qp --requires libphodav-2.0-1.fc22.x86_64.rpm 
/sbin/ldconfig
/sbin/ldconfig
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libgio-2.0.so.0()(64bit)
libglib-2.0.so.0()(64bit)
libgobject-2.0.so.0()(64bit)
libpthread.so.0()(64bit)
libsoup-2.4.so.1()(64bit)
libxml2.so.2()(64bit)
libxml2.so.2(LIBXML2_2.4.30)(64bit)
libxml2.so.2(LIBXML2_2.6.0)(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
rtld(GNU_HASH)

Comment 7 Adam Williamson 2015-04-15 15:54:41 UTC
Kalev notes:

<kalev> adamw: re your last comment, one thing that sticks out there is the 0: epoch
<kalev> I wonder if it's possible that this is messing something up?
 rpm -qp --obsoletes libphodav-2.0-1.fc22.x86_64.rpm 
 libphodav-1.0 <= 0:0.4-6
<kalev> usually this is done without epoch, I believe

i.e. the line should be:

Obsoletes:      libphodav-1.0 <= 0.4-6

I'm going to test this theory out.

Comment 8 Adam Williamson 2015-04-15 16:48:27 UTC
That theory doesn't work unfortunately: I built a 2.0-1.1.fc22 with the Obsoletes: line changed, added it to a side repo, and tried an update, it still fails in the same way.

I also confirmed that both yum and dnf work correctly. 'dnf update spice-gtk3':

Dependencies resolved.
================================================================================
 Package          Arch         Version              Repository             Size
================================================================================
Installing:
 libphodav        x86_64       2.0-1.1.fc22         phodav                 47 k
     replacing  libphodav-1.0.x86_64 0.4-5.fc22
Upgrading:
 spice-glib       x86_64       0.28-2.fc22          updates-testing       359 k
 spice-gtk3       x86_64       0.28-2.fc22          updates-testing        57 k

Transaction Summary
================================================================================
Install  1 Package
Upgrade  2 Packages

'yum update spice-gtk3':

Dependencies Resolved

================================================================================
 Package          Arch         Version              Repository             Size
================================================================================
Installing:
 libphodav        x86_64       2.0-1.1.fc22         phodav                 47 k
     replacing  libphodav-1.0.x86_64 0.4-5.fc22
Updating:
 spice-gtk3       x86_64       0.28-2.fc22          updates-testing        57 k
Updating for dependencies:
 spice-glib       x86_64       0.28-2.fc22          updates-testing       359 k

Transaction Summary
================================================================================
Install  1 Package
Upgrade  1 Package (+1 Dependent package)

Comment 9 Kalev Lember 2015-04-15 19:52:02 UTC
OK, I've got to the bottom of the problem now. It turned out to be an actual issue in the PackageKit stack after all.

Unsure why it only came up now and not before -- could be that rpm in F22 is doing more checks for the transaction check compared to what the F21 rpm was doing.

Comment 10 Fedora Update System 2015-04-15 19:55:14 UTC
libhif-0.2.0-2.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/libhif-0.2.0-2.fc22

Comment 11 Adam Williamson 2015-04-15 20:09:05 UTC
I'm +1 blocker on this, we've considered the 'graphical updates at Beta' criterion multiple times and accepted it. I was willing to consider various bits of chicanery we could do to try and resolve this without a respin, but they all seem to have issues, and Kalev's fix works for me, so I vote we do an RC3 with the fix.

Comment 12 Dennis Gilmore 2015-04-15 20:11:46 UTC
sadly I am +1 also, while it has an easy workaround, many users are likely to go oh the updater is broken.

Comment 13 Kalev Lember 2015-04-15 20:16:02 UTC
+1 blocker here as well.

Comment 14 Kevin Fenzi 2015-04-15 20:23:24 UTC
:( +1 blocker

Comment 15 Adam Williamson 2015-04-15 22:01:01 UTC
That's 4 +1s, marking as AcceptedBlocker. I'm just running some further tests on the update before requesting an RC3.

Kalev says:

<kalev> adamw: a small wrinkle is that the new libhif build doesn't work with the PackageKit that's in stable
 adamw: would be good to pull in PackageKit from https://admin.fedoraproject.org/updates/FEDORA-2015-5882 if you're taking libhif 0.2.0

but I tested with a clean Beta RC2 install and the updated libhif alone gave a successful offline update. I'm doing some further tests and trying to clarify with kalev now.

Comment 16 Kamil Páral 2015-04-16 07:37:45 UTC
I have tested with RC2 + libhif-0.1.8-8.fc22, which should be included in RC3, and the offline update worked correctly. Waiting for someone to test with clean RC3 as well.

Comment 17 Lukas Brabec 2015-04-16 08:14:36 UTC
I tested this with RC3, offline updates worked as expected, system was updated.

Comment 18 Fedora Update System 2015-04-17 02:30:31 UTC
libhif-0.1.8-8.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.


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