Bug 356871

Summary: yum upgrade to F8 gives package conflicts and skipped upgrades
Product: [Fedora] Fedora Reporter: Mads Kiilerich <mads>
Component: yumAssignee: Jeremy Katz <katzj>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 8CC: ffesti, james.antill, pmatilai, tim.lauridsen
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-17 17:10:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
rpm -qV for the strange packages none

Description Mads Kiilerich 2007-10-29 16:19:24 UTC
Description of problem:
After "yum upgrade" to test3 (according to
https://fedoraproject.org/wiki/Tools/yum/YumUpgradeFaq) some packages are left
not upgraded or with multiple versions installed simultaneously.
The packages are listed by 
package-cleanup --orphans|grep -v lvn|grep -v kernel


How reproducible:
It happened to me on my system - I don't know how to reproduce it

Actual results:
# yum list eclipse-subclipse eclipse-subclipse-book avahi krbafs-devel krbafs
bluez-utils tux usbview
Installed Packages
avahi.i386                               0.6.17-1.fc7           installed       
avahi.i386                               0.6.21-6.fc8           installed       
bluez-utils.i386                         3.9-2.fc7              installed       
bluez-utils.i386                         3.20-3.fc8             installed       
eclipse-subclipse.i386                   1.2.4-2.fc7            installed       
eclipse-subclipse-book.i386              1.2.4-2.fc7            installed       
krbafs.i386                              1.2.2-10.1             installed       
krbafs-devel.i386                        1.2.2-10.1             installed       
tux.i386                                 3.2.18-9.fc6           installed       
usbview.i386                             1:1.0-1                installed       
Available Packages
eclipse-subclipse.i386                   1.2.2-6.fc8            fedora          
eclipse-subclipse-book.i386              1.2.2-6.fc8            fedora          


Expected results:
As it is in the listing above I would expect "yum upgrade" to upgrade
eclipse-subclipse.
Upgrading should upgrade packages, not install conflicting copies

Additional info:
The output of 
for a in $(rpm -q eclipse-subclipse eclipse-subclipse-book avahi krbafs-devel
krbafs bluez-utils tux usbview); do echo $a; rpm -qV $a; done
has been attached

This problem could perhaps affect upgrades to the final F8 soon to be released,
so I have set the severity to high - please lower it if that is too high.

Comment 1 Mads Kiilerich 2007-10-29 16:19:24 UTC
Created attachment 242041 [details]
rpm -qV for the strange packages

Comment 2 seth vidal 2007-10-29 16:23:00 UTC
eclipse-subclipse - depending on when you did the update the prior ones could
have just been available


the other items are related to failed uninstall scriptlets which abort the
package removal at the rpm layer but in a non-fatal way.

try this:

rpm -e avahi-0.6.17-1.fc7

I bet it emits an error about a scriptlet failing.

run: rpm -e --noscripts avahi-0.6.17-1.fc7 

and it will be removed

the same is probably true for the rest.



Comment 3 Mads Kiilerich 2007-10-30 09:40:13 UTC
You are absolutely right about avahi. 

But yum fails to report the failing %postun:

[root@localhost ~]# rpm -ihv avahi-0.6.17-1.fc7.i386.rpm --nodeps
Preparing...                ########################################### [100%]
   1:avahi                  ########################################### [100%]
[root@localhost ~]# rpm -q avahi
avahi-0.6.17-1.fc7
[root@localhost ~]# yum upgrade
Setting up Upgrade Process
Resolving Dependencies
--> Running transaction check
---> Package avahi.i386 0:0.6.21-6.fc8 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Updating:
 avahi                   i386       0.6.21-6.fc8     development       235 k

Transaction Summary
=============================================================================
Install      0 Package(s)         
Update       1 Package(s)         
Remove       0 Package(s)         

Total download size: 235 k
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating  : avahi                        ######################### [1/2] 
  Cleanup   : avahi                        ######################### [2/2] 

Updated: avahi.i386 0:0.6.21-6.fc8
Complete!
[root@localhost ~]# rpm -q avahi
avahi-0.6.17-1.fc7
avahi-0.6.21-6.fc8
[root@localhost ~]# rpm -e avahi-0.6.17-1.fc7
error: %postun(avahi-0.6.17-1.fc7.i386) scriptlet failed, exit status 1
[root@localhost ~]# 

Ain't that a yum bug?

And avahi.fc7 postun shouldn't fail on f8, right?


eclipse-subclipse fails to upgrade because the f8 version is older than the f7
version.

- and the rest was other problems, but nothing important.


Comment 4 Seth Vidal 2007-10-30 12:43:15 UTC
check /var/log/yum.log - see if the error output about avahi is there.




Comment 5 Mads Kiilerich 2007-10-31 10:28:08 UTC
Nope

[root@localhost ~]# date
Wed Oct 31 11:24:24 CET 2007
[root@localhost ~]# rpm -ihv avahi-0.6.17-1.fc7.i386.rpm --nodeps
Preparing...                ########################################### [100%]
   1:avahi                  ########################################### [100%]
[root@localhost ~]# yum upgrade avahi
Setting up Upgrade Process
Resolving Dependencies
--> Running transaction check
---> Package avahi.i386 0:0.6.21-6.fc8 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Updating:
 avahi                   i386       0.6.21-6.fc8     fedora            235 k

Transaction Summary
=============================================================================
Install      0 Package(s)         
Update       1 Package(s)         
Remove       0 Package(s)         

Total download size: 235 k
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating  : avahi                        ######################### [1/2] 
  Cleanup   : avahi                        ######################### [2/2] 

Updated: avahi.i386 0:0.6.21-6.fc8
Complete!
[root@localhost ~]# rpm -q avahi
avahi-0.6.17-1.fc7
avahi-0.6.21-6.fc8
[root@localhost ~]# rpm -e avahi-0.6.17-1.fc7
error: %postun(avahi-0.6.17-1.fc7.i386) scriptlet failed, exit status 1
[root@localhost ~]# tail -n2 /var/log/yum.log
Oct 31 11:17:32 Updated: rhythmbox-debuginfo - 0.11.2-10.fc8.i386
Oct 31 11:25:00 Updated: avahi - 0.6.21-6.fc8.i386
[root@localhost ~]# 



Comment 6 Seth Vidal 2007-12-07 03:52:08 UTC
Jeremy, where are we shoving the scriptlet output now? I thought we were kicking
it out to the logs.

Comment 7 Jeremy Katz 2007-12-10 18:27:08 UTC
The simple callback write now is just printing the output.  Logging is ...
complicated from the point of view of syslog being an async mechanism and lines
of script output being out of order with the package they're associated with
could be really confusing

Comment 8 Seth Vidal 2008-03-12 15:24:33 UTC
this is just another bug where we need our logging and transaction errors better
reported.

Comment 9 Seth Vidal 2008-03-17 17:10:31 UTC
closing this b/c the problem is better documented elsewhere.

Comment 10 Mads Kiilerich 2008-03-17 23:27:01 UTC
Ok. Documented where?

(Asking because I don't find it obvious where it is documented and would 1. like
to understand the situation 2. leave a pointer.)