Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 228377 - multi-lib conflicts
Summary: multi-lib conflicts
Alias: None
Product: Fedora
Classification: Fedora
Component: oddjob
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: FE7Target
TreeView+ depends on / blocked
Reported: 2007-02-12 20:21 UTC by Michael Schwendt
Modified: 2007-12-08 10:38 UTC (History)
0 users

Fixed In Version: 0.29-1.fc8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-12-08 10:38:31 UTC

Attachments (Terms of Use)

Description Michael Schwendt 2007-02-12 20:21:00 UTC
oddjob - 0.27-9.x86_64
  Conflicts: 6
  File conflict in:
  Packages with the same files:
     oddjob - 0.27-9.i386

Comment 1 Nalin Dahyabhai 2007-02-13 00:13:50 UTC
Are we installing both arches of the main package?  I split off the -libs
subpackage so that we wouldn't have to do that.

Comment 2 Michael Schwendt 2007-02-13 10:06:16 UTC
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.

Comment 3 Nalin Dahyabhai 2007-02-13 16:08:58 UTC
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
  Requires: %{name} = %{version}-%{release}
  Requires: %{name}-libs = %{version}-%{release}
should fix this.  Giving it a try.

Comment 4 Michael Schwendt 2007-02-13 17:05:15 UTC
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*,
the split packages were fine:

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

Comment 5 Michael Schwendt 2007-02-13 17:05:51 UTC
error: %changelog not in descending chronological order
error: query of specfile oddjob.spec failed, can't parse

Comment 6 Nalin Dahyabhai 2007-02-13 22:04:36 UTC
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.

Comment 7 Nalin Dahyabhai 2007-09-05 21:17:10 UTC
Splitting off into a subpackage for 0.29.

Note You need to log in before you can comment on or make changes to this bug.