Bug 453512 – app-admin/setools depends on swig-1 but libsemanage and others on swig-2, causing dependency conflicts

• Product: Gentoo Linux
• Status: VERIFIED FIXED

[Description Jaakko Perttilä 2013-01-22 11:01:46 UTC]

# equery g --depth=3 =sys-apps/policycoreutils-2.1.13-r6

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-lang/swig:0

  (dev-lang/swig-1.3.40-r1::gentoo, ebuild scheduled for merge) pulled in by
  <dev-lang/swig-2.0 required by (app-admin/setools-3.3.7-r6::gentoo, ebuild scheduled for merge)

  (dev-lang/swig-2.0.8::gentoo, ebuild scheduled for merge) pulled in by
  >=dev-lang/swig-2.0.4-r1 required by (sys-libs/libsemanage-2.1.9::gentoo, ebuild scheduled for merge)


Reproducible: Always

Steps to Reproduce:
1. emerge -eav world



dev-python/sepolgen-1.1.8: sepolgen/policygen.py seems to work without setools.

Suggested fix: Unless setools is really needed, drop the dependency from sepolgen until it works with swig-2.0.

[Comment 1 Sven Vermeulen (RETIRED) 2013-01-27 12:05:49 UTC]

Sadly, setools is really needed.

The dependency is only build-time, so it should be possible to upgrade setools first, and then have world update again.

[Comment 2 Penetsdorfer Martin 2013-01-28 17:46:09 UTC]

same problem on ~amd64

[Comment 3 Sven Vermeulen (RETIRED) 2013-02-07 19:36:32 UTC]

This one is going to linger for (quite) some time, until upstream decides to support recent swig with setools. I've reported it on the mailinglist with a first patch, but except that it was over a thousand lines long, it also broke some stuff in weird places (so not applied upstream) and I have no idea how to deal with it further :-(

[Comment 4 Penetsdorfer Martin 2013-02-11 22:06:50 UTC]

On 2013-01-16 was released setools-3.3.8!

I'm a newbie, but it's possible to solve the new release of setools this problem

[Comment 5 Sven Vermeulen (RETIRED) 2013-02-18 19:03:14 UTC]

I'll have 3.3.8 in the tree soon, but the changelog doesn't mention anything swig related, so I'm afraid this release too still requires swig-1.

[Comment 6 Sven Vermeulen (RETIRED) 2013-03-08 19:32:34 UTC]

setools-3.3.8 is in hardened-development overlay, but still requires swig-1.

[Comment 7 Vadim A. Misbakh-Soloviov (mva) 2013-03-24 13:07:24 UTC]

*** Bug 462950 has been marked as a duplicate of this bug. ***

[Comment 8 Sven Vermeulen (RETIRED) 2013-04-21 10:36:31 UTC]

I'm looking into SLOT'ing swig-1

[Comment 9 Sven Vermeulen (RETIRED) 2013-04-21 11:10:16 UTC]

When swig-1 is SLOT'ed, we can depend on swig:1 instead of "<swig-2" and the dependency conflict is resolved. We do need to modify the setools ebuild a bit (all make calls have to have a SWIG=swig1.3). I'll attach this modified ebuild and will commit when the SLOTing of swig-1.3 is done.

[Comment 10 Sven Vermeulen (RETIRED) 2013-04-21 11:11:04 UTC]

Created attachment 346176 [details]
setools-3.3.8-r2 ebuild

Ebuild that calls swig1.3 instead of swig.

[Comment 11 Sven Vermeulen (RETIRED) 2013-04-22 18:38:56 UTC]

SLOT'ed swig-1 is committed to the tree as well as setools-3.3.8-r2 that depends on it (and uses it).

[Comment 12 Michael Jones 2013-05-11 01:30:02 UTC]

3.3.8-r1 fails to build, we could mitigate this stablizing 3.3.8-r2 or applying the patches to 3.3.8-r1

[Comment 13 Sven Vermeulen (RETIRED) 2013-05-11 10:42:46 UTC]

i'll stabilize -r2 in due time for this; you can temporarily accept_keywords this specific package/version for now and report if you get any additional problems