upgrading f11 -> rawhide: verifying the general technique for debugging

[Robert P. J. Day]

  (if you can stand one more post on the topic, i'm still working on
this for the entertainment value, and also to school myself in the
intricacies of debugging upgrades of this complexity.  and now, to the
specific example.)

  just to see how much upgrading this would involve, i tried the
following:

# yum upgrade udev

fully expecting to see *piles* of packages that would have to come
along for the ride, and i was not disappointed:

...
Transaction Summary
================================================================================
Install      44 Package(s)
Upgrade     287 Package(s)

Total size: 380 M
...

  further up the output, we have this verification:

Installing:
... snip ...
 udev               x86_64 145-12.fc12     rawhide 303 k
     replacing  udev-extras.x86_64 20090226-0.5.20090302git.fc11


 ok, all the dependencies were resolved so just let it go and see what
happens:

...
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test


Transaction Check Error:
  file /lib/udev/hid2hci from install of udev-145-12.fc12.x86_64
    conflicts with file from package bluez-4.42-9.fc11.x86_64
  file /lib/udev/rules.d/70-hid2hci.rules from install of udev-145-12.fc12.x86_64
    conflicts with file from package bluez-4.42-9.fc11.x86_64
#

  um ... what?  why should the new udev conflict with the *existing*
bluez given that bluez should be upgraded as well?

# yum list bluez\*
Loaded plugins: downloadonly, fastestmirror, refresh-packagekit
Loading mirror speeds from cached hostfile
 * fedora: fedora.mirror.iweb.ca
 * rawhide: mirror.its.uidaho.edu
 * rpmfusion-free: mirrors.tummy.com
 * rpmfusion-free-rawhide: mirrors.tummy.com
 * rpmfusion-free-updates: mirrors.tummy.com
 * rpmfusion-free-updates-testing: mirrors.tummy.com
 * updates: fedora.mirror.iweb.ca
Installed Packages
bluez.x86_64                                4.42-9.fc11                 @updates
bluez-cups.x86_64                           4.42-9.fc11                 @updates
bluez-libs.x86_64                           4.42-9.fc11                 @updates
Available Packages
bluez.x86_64                                4.57-2.fc12                 rawhide
bluez-alsa.i586                             4.42-9.fc11                 updates
bluez-alsa.i686                             4.57-2.fc12                 rawhide
bluez-alsa.x86_64                           4.57-2.fc12                 rawhide
bluez-compat.x86_64                         4.57-2.fc12                 rawhide
bluez-cups.x86_64                           4.57-2.fc12                 rawhide
bluez-gnome.x86_64                          1.8-16.fc11                 fedora
bluez-gnome-analyzer.x86_64                 1.8-16.fc11                 fedora
bluez-gstreamer.i586                        4.42-9.fc11                 updates
bluez-gstreamer.i686                        4.57-2.fc12                 rawhide
bluez-gstreamer.x86_64                      4.57-2.fc12                 rawhide
bluez-hcidump.x86_64                        1.42-4.fc12                 rawhide
bluez-libs.i586                             4.42-9.fc11                 updates
bluez-libs.i686                             4.57-2.fc12                 rawhide
bluez-libs.x86_64                           4.57-2.fc12                 rawhide
bluez-libs-devel.i586                       4.42-9.fc11                 updates
bluez-libs-devel.i686                       4.57-2.fc12                 rawhide
bluez-libs-devel.x86_64                     4.57-2.fc12                 rawhide
#

  as i read the above (and correct me if i'm doing this incorrectly),
i certainly see a newer (rawhide) version of bluez that i would have
thought would be part of the upgrade, but apparently it isn't.

  if i go back through the lengthy list of packages to be
installed/upgraded, nothing of the form "bluez*" is listed.  why not?
it's listed as available, it's clearly(?) in rawhide, but it's somehow
not being picked up in this sizable upgrade.

  how *would* one interpret the above diagnostic?

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================