It's almost certainly a packaging bug in mysql ( nothing Provides real-mysql%{?_isa} )

and... nothing rel-eng can/should do about that, that's something for pkg maintainer to fix.

Replying to [comment:1 rdieter]:

It's almost certainly a packaging bug in mysql ( nothing Provides real-mysql%{?_isa} )

Nothing provides it in x86_64 repo, because the package mysql-5.5.30-1.fc19.i686 is not there. In i686 repo there is:

{{{
$ repoquery --whatprovides 'real-mysql-devel(x86-32)' --disablerepo=* --enablerepo=rawhide --archlist=i686
mysql-devel-0:5.5.30-1.fc19.i686
}}}

So I still think it's up to rel-eng to include mysql-5.5.30-1.fc19.i686 in x86_64 if there is mysql-devel-5.5.30-1.fc19.i686 there.

To summarize the above comment to a simple question: "Why mysql.i686 and mysql-embedded.i686 are not included in x86_64 repositories?"

Also re-opening since otherwise it could be forgotten without answer.

still a packaging bug. if you insist, file something against mysql @ bugzilla.redhat.com

OK, looking closer, looks like the problems may actually conflicts between mariadb and mysql.

mariadb currently Obsoletes mysql, so some if it's packages are no longer getting included and multilib'd properly.

Suggestions include:
1. drop Obsoletes from mariadb (as long as fedora still provides any real package named mysql)
2. retire 'mysql' package, and re-review and bring back named as something else (like real-mysql)
3. some other better solution ??

Replying to [comment:5 rdieter]:

still a packaging bug. if you insist, file something against mysql @ bugzilla.redhat.com

Just fyi I'm actually on of the packagers of mariadb and mysql.

Replying to [comment:6 rdieter]:

OK, looking closer, looks like the problems may actually conflicts between mariadb and mysql.

Yes, they conflict explicitly, all packages conflict including -devel, so I don't see the reason why only -devel is included but not the base package.

mariadb currently Obsoletes mysql, so some if it's packages are no longer getting included and multilib'd properly.

Again, all mariadb packages obsolete the same mysql alternatives, so I'm still getting the point why mysql-embedded-devel package should behave in a different manner than mysql-embedded.

Suggestions include:
1. drop Obsoletes from mariadb (as long as fedora still provides any real package named mysql)
2. retire 'mysql' package, and re-review and bring back named as something else (like real-mysql)
3. some other better solution ??

What about 4.: Dropping all 32bit mysql packages from x86_64 repository. We have already 32bit mariadb packages instead of them and they should be actually used.

How is the list of multilib packages actually handled? Could I as a packager to add or remove multilib packages or you can do it? Or is that somehow generated?

The simple rules mash uses to determine if a pkg should be multilib'd is: 1. is it named -devel , 2. does it contain shared libraries (anything matching /lib/lib.so.), plus a bunch of other stuff, but that should give you the general idea. packagers generally do not have control of this.

For details, install 'mash' pkg, and examine multilib.py

Replying to [comment:8 rdieter]:

The simple rules mash uses to determine if a pkg should be multilib'd is: 1. is it named -devel , 2. does it contain shared libraries (anything matching /lib/lib.so.), plus a bunch of other stuff, but that should give you the general idea. packagers generally do not have control of this.

For details, install 'mash' pkg, and examine multilib.py

Thanks for the explanation, it does answer why -devel packages are included. But still -- if we include -devel packages, then we need also all it's dependencies. But if we cannot include depended packages because they are obsoleted, we shouldn't include the -devel packages either (they're obsoleted in the same way).

So I see actually two ways how to solve that:
1. teach mash to ignore obsoleted packages from multilib
2. add mysql packages to blacklist in mash

Replying to [comment:9 hhorak]:

So I see actually two ways how to solve that:
1. teach mash to ignore obsoleted packages from multilib

Actually I believe this would be the right solution, so I reported a bug against mash: rhbz# 913556.

k, things should get resolved once the mash issue is resolved, not much else rel-eng'y to do here.