Bug 228377 - multi-lib conflicts
multi-lib conflicts
Product: Fedora
Classification: Fedora
Component: oddjob (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Fedora Extras Quality Assurance
Depends On:
Blocks: FE7Target
  Show dependency treegraph
Reported: 2007-02-12 15:21 EST by Michael Schwendt
Modified: 2007-12-08 05:38 EST (History)
0 users

See Also:
Fixed In Version: 0.29-1.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-08 05:38:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Schwendt 2007-02-12 15:21:00 EST
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-12 19:13:50 EST
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 05:06:16 EST
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 11:08:58 EST
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 12:05:15 EST
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
Comment 5 Michael Schwendt 2007-02-13 12:05:51 EST
error: %changelog not in descending chronological order
error: query of specfile oddjob.spec failed, can't parse
Comment 6 Nalin Dahyabhai 2007-02-13 17:04:36 EST
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 17:17:10 EDT
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.