# 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-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)
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.
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.
same problem on ~amd64
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 :-(
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
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.
setools-3.3.8 is in hardened-development overlay, but still requires swig-1.
*** Bug 462950 has been marked as a duplicate of this bug. ***
I'm looking into SLOT'ing swig-1
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.
Created attachment 346176 [details]
Ebuild that calls swig1.3 instead of swig.
SLOT'ed swig-1 is committed to the tree as well as setools-3.3.8-r2 that depends on it (and uses it).
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
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