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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
