On Mon, 9 Nov 2009, Robert P. J. Day wrote:
On Mon, 9 Nov 2009, Adam Williamson wrote:
On Mon, 2009-11-09 at 14:24 -0500, Seth Vidal wrote:
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.
I think it's just that only trying to upgrade udev - as he's doing -
doesn't cause a newer bluez to be pulled in. I don't see why it
should, it doesn't make any sense for udev to have a dependency on
bluez. I don't think we exactly support 'yum upgrade
$SOME_REALLY_IMPORTANT_PACKAGE' from a Rawhide repo when you're
running a stable release. Even less so than we support 'yum
upgrade'.
i'm tempted to agree, except that the error clearly shows that the
new udev conflicts with an existing bluez file, so obviously there's
*some* kind of inter-relationship there that doesn't seem to exist
with the *newer* bluez packages.
in any event, i just did
# yum upgrade bluez\*
and that did the trick -- i'm now in the midst of a 300+ package
upgrade. but i BZed this anyway:
https://bugzilla.redhat.com/show_bug.cgi?id=533925
someone else can decide if, somehow, udev and bluez need to learn how
to play nice.
the problem is this.
we can't tell if there is a file conflict until AFTER the dep resolution
is done and the pkgs are downloaded. This is b/c we don't have the
checksums of all the files in the metadata. And I'd bet we don't want it,
either. It'd make everything even more hugerrific.
-sv
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
