Bug 244648

Summary: pup: conflicting requirements in updates cause unhandled exception
Product: [Fedora] Fedora Reporter: David Timms <dtimms>
Component: pirutAssignee: Jeremy Katz <katzj>
Severity: medium Docs Contact:
Priority: low    
Version: 7Keywords: Reopened
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-06-18 21:13:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
exception trace none

Description David Timms 2007-06-18 11:27:10 UTC
Description of problem:
pirut aborts with exception trying to update {19 packages to do}.

Version-Release number of selected component (if applicable):

How reproducible:
At the moment yes. I deselected about half the packages {including kernel} which
installed OK. Repeating with rest of updates causes exception.

Steps to Reproduce:
1. terminal
2. pup
3. apply
Actual results:
exception {request to save}

Expected results:
resolve, download, install updates.

Additional info:
standard fedora.repo
modified fedora-updates.repo:
name=Fedora $releasever - $basearch - Updates
{yum.conf: failovermethod=priority}

It is definite that the first listed mirror does not have the kernel rpm, nor
it's headers {actually, it doesn't have the repodata either - this was retrieved
from another mirror when infrastructure-server wasn't available}.

A wireshark network trace shows no data tx/rx between clicking apply, and the
crash, which happens with the resolving dependencies at progress ~20-30%.
With a direct yum run, the following packages are set for update:
yum update
Loading "installonlyn" plugin
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package libexif.i386 0:0.6.15-2.fc7 set to be updated
---> Package libvirt-python.i386 0:0.2.3-1.fc7 set to be updated
---> Package libxml2-python.i386 0:2.6.29-1.fc7 set to be updated
---> Package libxml2.i386 0:2.6.29-1.fc7 set to be updated
---> Package libxslt-devel.i386 0:1.1.21-1.fc7 set to be updated
---> Package libvirt.i386 0:0.2.3-1.fc7 set to be updated
---> Package libxslt.i386 0:1.1.21-1.fc7 set to be updated
---> Package kernel.i686 0:2.6.21-1.3228.fc7 set to be updated
---> Package kernel-headers.i386 0:2.6.21-1.3228.fc7 set to be updated
---> Package libxml2-devel.i386 0:2.6.29-1.fc7 set to be updated
---> Package kernel-devel.i686 0:2.6.21-1.3228.fc7 set to be updated
---> Package liboil.i386 0:0.3.12-3.fc7 set to be updated
---> Package libraw1394.i386 0:1.2.1-8.fc7 set to be updated
--> Processing Conflict: libraw1394 conflicts kernel < 2.6.21-1.3194.fc7
Error: No Package Matching kernel.i686

I think this situation:
1. needs a nicer dialog
2. preferably it should simply exclude packages until either the update can
work, or every available update has been excluded.

Comment 1 David Timms 2007-06-18 11:27:11 UTC
Created attachment 157270 [details]
exception trace

Comment 2 Ignacio Vazquez-Abrams 2007-06-18 11:30:03 UTC

*** This bug has been marked as a duplicate of 244474 ***

Comment 3 David Timms 2007-06-18 12:13:39 UTC
Ignacio, thanks for that. However, in
Jarod mentions creating a bug that is actually concerned with the error message
provided in the GUI, which is really where most people probably see this error.
It doesn't seem that he has done that, so I'll make this Summary state that, and
I'll un-dupe it.
These bad inputs should really be happily handled in the pup GUI.
Consider this a clone split of bug 244474.

Comment 4 Jeremy Katz 2007-06-18 21:13:38 UTC
It's done, so I'll dupe against that one

*** This bug has been marked as a duplicate of 244488 ***