[rawhide] colord pulling in 32bit packages on 64bit installs

[Kalev Lember]

On 01/10/2013 09:23 PM, Kevin Fenzi wrote:
> Don't be sorry... it turns out that this is not an easy case to fix. :( 
> 
> It's a archfull package obsoleting/providing a noarch package. 
> 
> Yum picks the 32bit of the multiarched package to obsolete things. 
> 
> The only suggestion (thanks kalev) that looks like it might work is to
> setup noarch subpackages of colord that does the obsolete/provides,
> named the same as the ones it's replacing. 
> 
> Anyone else have any better solution here?

I can think of a cleaner solution, but this requires reworking the
colord packaging and might or might not be feasible.

Let me first describe the issue how I see it and then the solution.

The issue stems from the fact that we have two colord packages in the
x86_64 repo, because of multilib. One is colord.i686 and the other one
is colord.x86_64.

So yum sees a single installed package (shared-color-profiles.noarch)
and two replacements: colord.i686 and colord.x86_64. The default
behaviour for yum upgrade is to install all the packages where Obsoletes
match, so it installs both colord packages.

Now, the solution would be to make sure that only one package in the
repo replaces shared-color-profiles. Obviously, there's also the
possibility to change / fix yum, but I won't go there.

One hacky way (like Kevin mentioned above) to ensure there is only one
package replacing is to make the replacing package noarch. We could move
the ICC colour profiles to a new colord noarch subpackage and have it
obsolete shared-color-profiles. Or alternatively just name the new
subpackage "shared-color-profiles", the same as the old package. In that
case no obsoletes are necessary.

But the better solution I was thinking of is to split colord packaging
into two: one package with the shared library (colord-libs) and another
package with the daemon (colord). With a setup like this, only the
library subpackage would get multilibbed and the daemon package would
not. And then we could make the non-multilibbed daemon package obsolete
shared-color-profiles.

As to how feasible this is, I guess that's a question to Richard. Can
the 32 bit colord library talk to the 64 bit daemon?

-- 
Hope this helps,
Kalev