[rhelv6-list] is anyone else having multi-arch issues with neon?

[Michael Schwendt]

On Thu, 5 Sep 2013 11:43:15 -0400, Nalin Dahyabhai wrote:

> On Thu, Sep 05, 2013 at 10:11:40AM -0500, Leinweber, James wrote:
> > Running "sudo yum update -y" for the neon package fails thusly:
> > -----------------
> > Loaded plugins: downloadonly, refresh-packagekit, rhnplugin
> > This system is receiving updates from RHN Classic or RHN Satellite.
> > rhel-x86_64-server-6
> > | 1.8 kB     00:00
> > Setting up Update Process
> > Resolving Dependencies
> > --> Running transaction check
> > ---> Package microcode_ctl.x86_64 1:1.17-14.el6 will be updated
> > ---> Package microcode_ctl.x86_64 1:1.17-15.el6_4 will be an update
> > ---> Package neon.x86_64 0:0.29.3-2.el6 will be updated
> > --> Processing Dependency: neon = 0.29.3-2.el6 for package:
> > neon-devel-0.29.3-2.el6.x86_64
> > ---> Package neon.x86_64 0:0.29.3-3.el6_4 will be an update
> > --> Running transaction check
> > ---> Package neon.i686 0:0.29.3-2.el6 will be installed
> [snip]
> > Error:  Multilib version problems found. This often means that the root
> >        cause is something else and multilib version checking is just
> >        pointing out that there is a problem. Eg.:
> > 
> >          1. You have an upgrade for neon which is missing some
> >             dependency that another package requires. Yum is trying to
> >             solve this by installing an older version of neon of the
> >             different architecture. If you exclude the bad architecture
> >             yum will tell you what the root cause is (which package
> >             requires what). You can try redoing the upgrade with
> >             --exclude neon.otherarch ... this should give you an error
> >             message showing the root cause of the problem.
> 
> Does this system have neon-devel installed?

That's why I asked for the full output. ;-)  The answer is in there:

  --> Processing Dependency: neon = 0.29.3-2.el6 for package:  
  neon-devel-0.29.3-2.el6.x86_64 

Yes, that's the typical old-school non-arch-specific
  Requires: %name = %version-%release
base package dependency, which we make arch-specific at Fedora for
some time to avoid these dependency issues.

So, your theory has hit the nail on its head. Erasing neon-devel or
making available its update will fix the dependency issue.