Re: YUM update conflicts: 'glibc' and 'glibc-common' (F11, x86_64)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Aug 22, 2009 at 16:55, Kevin J. Cummings <cummings@xxxxxxxxxxxxxxxxxx> wrote:
On 08/22/2009 04:00 PM, Ryan Lynch wrote:
> On Sat, Aug 22, 2009 at 15:44, Kevin J. Cummings
> <cummings@xxxxxxxxxxxxxxxxxx <mailto:cummings@xxxxxxxxxxxxxxxxxx>> wrote:
>
>     On 08/22/2009 03:39 PM, Geoffrey Leach wrote:
>     > On 08/22/2009 12:24:08 PM, Kevin J. Cummings wrote:
>     >> On 08/22/2009 03:17 PM, Ryan Lynch wrote:
>     >>> Running 'yum update' from the command line, I am getting some file
>     >>> conflicts between different arch/versions of the 'glibc' and
>     >>> 'glibc-common' packages.  This machine runs F11-x86_64.
>     >>>
>     >>> Here's the actual error output:
>     >>>
>     >>> <code>
>     >>> Transaction Check Error:
>     >>>   file /usr/share/doc/glibc-2.10.1/NEWS from install of
>     >>> glibc-2.10.1-4.i686 conflicts with file from package
>     >> glibc-2.10.1-2.x86_64
>     >>>   file /usr/bin/ldd from install of glibc-common-2.10.1-4.i586
>     >> conflicts
>     >>> with file from package glibc-common-2.10.1-2.x86_64
>     >>>   file /usr/lib/locale/locale-archive.tmpl from install of
>     >>> glibc-common-2.10.1-4.i586 conflicts with file from package
>     >>> glibc-common-2.10.1-2.x86_64
>     >>>   file /usr/share/doc/glibc-common-2.10.1/ChangeLog.bz2 from
>     >> install
>     >> of
>     >>> glibc-common-2.10.1-4.i586 conflicts with file from package
>     >>> glibc-common-2.10.1-2.x86_64
>     >>>   file /usr/share/i18n/locales/de_AT from install of
>     >>> glibc-common-2.10.1-4.i586 conflicts with file from package
>     >>> glibc-common-2.10.1-2.x86_64
>     >>> </code>
>     >>>
>     >>> Is this a known issue, or did I screw something up?
>     >>
>     >> Something is screwed up.  Possibly on your system.  glibc-common.i586
>     >> is
>     >> conflicting with glibc-common.i686.  I think you need one and not the
>     >> other.  Since you system is a base x86_64, I would suggest trying the
>     >> following:
>     >>
>     >> # yum shell
>     >>> remove glibc-common.i586
>     >>> install glibc-common.i686
>     >>> run
>     >>
>     >> and see if that helps....
>     >
>     > Hmmmm ... perhaps install glibc-common.x86_64? i686 is still 32 bit.
>
>     Not if its a multi-lib problem.  I assumed that the x86_64 part would
>     straighten itself out....  But yes, he needs to ensure that all of his
>     secondary libs are either all i586 or all i686 (where he has a choice
>     between the two) and that they co-exist well with their x86_64
>     counterparts (which should be the primary concern anyways).
>
>
>
> Here's the output of `yum list installed glibc-common glibc`, for reference:
>
> <code>
> Installed Packages
> glibc.i686                      2.10.1-2                      installed
> glibc.x86_64                  2.10.1-2                      installed
> glibc-common.x86_64    2.10.1-2                      installed
> </code>
>
> I tried `yum remove glibc.i686`, but it wants to remove 116 packages,
> for dependencies.  Mostly, it looks like stuff I installed while getting
> Skype for Linux to run, so I'm pretty sure its going to break some
> things if I remove it all.
Ryan,
       You are barking up the wrong tree.  Your problem is
glibc-common.i586.  Something is trying to install this package and it
conflicts with your currently installed glibc-common.i686.
You need to track down where that dependency is coming from and deal
with it.


No, I'm pretty sure that's the right tree :-)  I didn't post the whole output of 'yum update', though, so that's not your fault.  See below.

 
> Isn't this a packaging bug?  There's no conflict between my
> currently-installed 'glibc.i686' and 'glib.x86_64' (2.10.1-2), although
> there is a conflict between the two archs' 'glibc-common' packages.


Possibly, but we need to know what is causing it first.  i586/i686 are
not meant to be multilib (like x86_64/i686 is).


I don't mean to be rude, but I think you have some misconceptions about how i686 and i586 work on Fedora, before we go any further:

 * There is no glibc-common.i686 package.  It doesn't exist, either on my system or anywhere in stable Fedora.  Go take a look at at the repos, right now, and confirm that.  (There is such a package in Rawhide, but that's not relevant, here.)

 * Many source RPMs don't have an i686 binary package, at all.  Instead, they have an i586 or i386 package for 32-bit.  OpenSSH is like this (go check for yourself), and there are others.  I don't exactly know why this is, but it's perfectly valid to have a mix of i586 and i686 packages on a Fedora system.

 * glibc-2.10.1-4.i686 is the package causing YUM to pull in glibc-common.i586.  Here's the snippet from my original 'yum update' command:

<output>
---> Package glibc.i686 0:2.10.1-4 set to be updated               
--> Processing Dependency: glibc-common = 2.10.1-4 for package: glibc-2.10.1-4.i686
</output>

 * glibc-2.10.1-2.i686 depends on 'glibc-common = 2.10.1-2', but it apparently tolerates either the i586 OR the x86_64 version of 'glibc-common'.  The 2.10.1-4.i686 update, however, changed its dependencies:  It only accepts the i586 arch of 'glibc-common'.  You can confirm this by comparing:

    - `yum deplist glibc-2.10.1-2.i686 | grep glibc-common`:
<output>
  dependency: glibc-common = 2.10.1-2
   provider: glibc-common.x86_64 2.10.1-2
   provider: glibc-common.i586 2.10.1-2
  dependency: glibc-common = 2.10.1-2
   provider: glibc-common.x86_64 2.10.1-2
   provider: glibc-common.i586 2.10.1-2
</output>

against:

    - `yum deplist glibc-2.10.1-4.i686 | grep glibc-common`:
<output>
  dependency: glibc-common = 2.10.1-4
   provider: glibc-common.i586 2.10.1-4
</output>

IN SHORT:  The package 'glibc.i686' changes its dependencies from the -2 release to -4.  Previously, my 'glibc-common.x86_64' was sufficient to satisfy 'glibc.i686', whereas now, it *must* have 'glibc-common.i586'.

All that make sense?  I think at this point, I need to find out why that change happened, and whether there's anything to be done about it upstream.

-Ryan


-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux