Bug 356871 - yum upgrade to F8 gives package conflicts and skipped upgrades
yum upgrade to F8 gives package conflicts and skipped upgrades
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
8
All Linux
low Severity high
: ---
: ---
Assigned To: Jeremy Katz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-29 12:19 EDT by Mads Kiilerich
Modified: 2014-01-21 17:59 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-17 13:10:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
rpm -qV for the strange packages (5.02 KB, text/plain)
2007-10-29 12:19 EDT, Mads Kiilerich
no flags Details

  None (edit)
Description Mads Kiilerich 2007-10-29 12:19:24 EDT
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 12:19:24 EDT
Created attachment 242041 [details]
rpm -qV for the strange packages
Comment 2 seth vidal 2007-10-29 12:23:00 EDT
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 05:40:13 EDT
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 08:43:15 EDT
check /var/log/yum.log - see if the error output about avahi is there.


Comment 5 Mads Kiilerich 2007-10-31 06:28:08 EDT
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-06 22:52:08 EST
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 13:27:08 EST
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 11:24:33 EDT
this is just another bug where we need our logging and transaction errors better
reported.
Comment 9 Seth Vidal 2008-03-17 13:10:31 EDT
closing this b/c the problem is better documented elsewhere.
Comment 10 Mads Kiilerich 2008-03-17 19:27:01 EDT
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.)

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