upgrading f11 -> rawhide: verifying the general technique for debugging
Seth Vidal
skvidal at fedoraproject.org
Mon Nov 9 19:24:58 UTC 2009
On Mon, 9 Nov 2009, Robert P. J. Day wrote:
>
> (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?
>
I would interpret it as impossible to decipher w/o the complete output.
Please file a bug about it and include the entire output - don't snip
anything out.
thanks,
-sv
More information about the test
mailing list