On Thu, 2007-04-05 at 19:14 +0200, Michael Schwendt wrote: > On Thu, 05 Apr 2007 13:02:14 -0400, David Zeuthen wrote: > > > On Thu, 2007-04-05 at 18:01 +0200, Mark wrote: > > > file /usr/share/hal/fdi/information/10freedesktop/10-usb-music-players.fdi from install of hal-0.5.9-1.fc7 conflicts with file from package hal-0.5.9-0.git20070304.fc7 > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235152 > > > > It would be nice if someone could tell me how to resolve this; last I > > checked all the rpm/yum wizards (including jkeating and skvidal) were > > all scratching their heads. Thanks. > > The error smells a lot like an i386<->x86_64 conflict. > Old i386 pkg versus new x86_64 pkg. > > Indeed, Rawhide only contains hal-0.5.9-1.fc7.x86_64.rpm and no hal.i386 Right. Here's a wordier explanation for folks trying to follow along at home: hal used to be multilib, so x86_64 systems got hal.i386 in addition to hal.x86_64. Now, hal has grown a hal-libs subpackage. Obviously, since the 'hal' package no longer contains libraries, it shouldn't be multilib. So there's no need for hal.i386 anymore, but yum doesn't know that - it tries to upgrade it like normal. (We currently have similar problems with mysql as well, but not everyone has mysql installed). AFAIK anaconda handles this case on a per-package basis - if you've got hal.i386 on an x86_64, it removes it and installs hal-libs.i386 instead. Maybe we need a similar workaround in multilib repositories until we have a proper solution in RPM? A static list of packages that are no longer multilib, and (optionally) the library packages that replace them? -w
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
