Description of problem: We need the 32 bit version of redhat-artwork installed, since several apps like HelixPlayer and openoffice use bluecurve but don't directly depend on the 32 bit redhat-artwork. How reproducible: Always Steps to Reproduce: 1. Install HelixPlayer 2. Run it 3. See incorrect theming
Can't we put the Requires: back in the packaging? :)
That sounds weird to me; you could use another theme, and in that case don't need redhat-artwork. On the other hand, so many other packages depend on redhat-artwork (rpm -q --whatrequires redhat-artwork), that adding another hardcoded dependency probably isn't a big deal. However - this does mean that any 32-bit third party apps would have to know to pull down redhat-artwork(32) if HelixPlayer/openoffice weren't installed.
To my knowledge, gtk2 has never Requires: redhat-artwork, if that is what is being suggested, it would create yet one more bootstrap loop in the distribution.
I think notting's suggestion was that 32-bit apps like HelixPlayer and OpenOffice should require redhat-artwork(32) individually. It seems a bit ugly to me, but I'm willing to do it for HelixPlayer if changing comps isn't desirable at this point. Dan, do you have an opinion?
Well, it's mainly that we already pull in redhat-artwork easily for 64-bit. Getting it to say 'if you include a 32-bit gtk app, include 32-bit redhat-artwork' isn't an easy change. But the package requirements isn't right either.
Do we install any other 32 bit libraries by default on x86_64? If so then adding redhat-artwork seems to be a fairly natural thing to me. If not, then let's just go with the individual package deps.
It's included in 'Compatibility Arch Support' already. But that's something the users can turn off, while still getting OOo, Helix, etc.
I see. And CAS isn't checked by default, apparently? I did a pretty much stock runthrough of anaconda on my em64t test box, and didn't get it. Let's go with the package dependencies. I'm reassigning this one to openoffice for Dan, and I'll do an upload of Helix now.
Ok, according to Nalin, Jeremy says there's no way for a package to require a 32-bit version of a package. Thus, I think this is a comps issue. Reassigning back.
And it turns out that comps can't do it. But after talking with notting on irc, we decided that HelixPlayer could Requires: libbluecurve.so, which is the 32 bit version. This is done in HelixPlayer-1.0.1.gold-6. It's a hack, but oh well.
Will also Require: libbluecurve.so in OOo