Are we installing both arches of the main package?  I split off the -libs
subpackage so that we wouldn't have to do that.

This ticket is purely based on checking repository metadata in an
automated way. The "oddjob" i386 main package has found its way into
the x86_64 repository through a -devel package dependency.

Splitting of a -libs packages sounds right.

Eek, you're right.  I forgot to change that requirement to point to the -libs
package.  Assuming that the -libs package's dependency on the main package
doesn't pull both versions of the main package into the repository, then I think
changing
  Requires: %{name} = %{version}-%{release}
to
  Requires: %{name}-libs = %{version}-%{release}
should fix this.  Giving it a try.

I've had a look into cvs:

* "oddjob-libs" explicitly Requires "oddjob". Hmm? In that case,
splitting of the -libs pkg is pointless, as it is tied to the main
package through this explicit dependency.

* oddjobs-libs also includes a Python module and a PAM module,
creating additional deps. The Python 32-bit module creates a
dep on python(abi) = ...

Conclusively, if oddjob-libs contained just the shared liboddjob.so.*,
the split packages were fine:

oddjob-devel => oddjob-libs
oddjob => oddjob-libs

error: %changelog not in descending chronological order
error: query of specfile oddjob.spec failed, can't parse

Yeah, aargh.  That happens all to me all the time.

I would have expected that the i386 oddjob-libs package's dependency on oddjob
would be satisfied by the x86_64 package, as there aren't any shared libraries
involved.  If that doesn't happen, then we're screwed.

The python module dependency, though, I'm not sure what to do about that. 
Splitting it off into another subpackage would solve it, but that's getting to
be a large number of subpackages.

Splitting off into a subpackage for 0.29.