Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 663440

Summary: catalyst fails to handle circular dependency on sys-libs/pam and sys-libs/libcap in stage3
Product: Gentoo Hosted Projects Reporter: Marcus Comstedt <marcus>
Component: CatalystAssignee: Gentoo Catalyst Developers <catalyst>
Status: UNCONFIRMED ---    
Severity: normal CC: bkohler, sam, xals
Priority: Normal    
Version: unspecified   
Hardware: PPC64   
OS: Linux   
Package list:
Runtime testing required: ---

Description Marcus Comstedt 2018-08-12 12:49:28 UTC
The version of libpam currently in portage has a circular dependency on libcap when the "filecaps" use flag is enabled (this is the default):

(sys-libs/pam-1.2.1-r2:0/0::gentoo, ebuild scheduled for merge) depends on
 (sys-libs/libcap-2.24-r2:0/0::gentoo, binary scheduled for merge) (buildtime)
  (virtual/pam-0-r1:0/0::gentoo, binary scheduled for merge) (runtime)
   (sys-libs/pam-1.2.1-r2:0/0::gentoo, ebuild scheduled for merge) (runtime)

The fix is to merge sys-libs/pam without filecaps, then sys-libs/libcap, and finally sys-libs/pam with filecaps.  Catalyst does not do this, so the only
workaround I've found is build the stage3 without filecaps (but that also leaves
a package.use disabling filecaps in /etc/portage of the stage).

Reproducible: Always

Steps to Reproduce:
1.Snapshot current portage
2.Build stage3 from the snapshot
Actual Results:  
stage3 build fails with a circular dependency, unless portage_confdir is used
to disable filecaps for sys-libs/pam

Expected Results:  
start3 builds correctly, with filecaps enabled for libpam (as is the default)
Comment 1 Marcus Comstedt 2018-08-12 12:53:12 UTC
Catalyst version: dev-util/catalyst-3.0.2
Comment 2 Ben Kohler gentoo-dev 2018-08-12 14:04:00 UTC
We (releng) have found that it's best to disable filecaps on the built stage, because the availability of caps/xattrs on the destination is not guaranteed.  If the packages are shipped with filecaps off but with a pending +filecaps USE change, then the ebuild logic can safely handle cases where USE=filecaps is on but the destination FS doesn't support it.

FYI if you set (eg) "portage_prefix: releng" in your specs, then 
/etc/portage/package.*/releng/ will be removed before packing the stage.  This is how you can set a temporary USE flag for the build but not keep the entry in the resulting stage's /etc/portage/ dir.

If this doesn't address your issue, I think this will need to be a major feature request bug, in either catalyst or portage.
Comment 3 Ben Kohler gentoo-dev 2018-08-12 14:04:59 UTC
Here is what releng sets temporarily, to be wiped/reset before the final packing:
Comment 4 Marcus Comstedt 2018-08-12 14:48:51 UTC
Thanks!  This does indeed fix my issue.

Somehow I feel that these (releng) settings should be the default (or at least mentioned in the FAQ) since things will not work without them, but now it works for me at least.  :-)
Comment 5 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2018-08-13 00:06:16 UTC
FTR, this is not a bug in catalyst as there's no "reasonable" way for an automated tool to workaround a manual process in portage. Portage itself is unable to deal with the circular dependencies and thus require manual action by the user.
As such, this should likely be closed as CANTFIX.
I agree we can try to make the PORTAGE_PREFIX variable better known.
Comment 6 timkenhan 2019-01-20 04:04:54 UTC
can we at least provide a clear instruction on how to get around this?
Comment 7 Alexis Lahouze 2019-03-28 08:21:01 UTC
*** Bug 681136 has been marked as a duplicate of this bug. ***
Comment 8 Matt Turner gentoo-dev 2021-01-26 01:26:08 UTC
(In reply to timkenhan from comment #6)
> can we at least provide a clear instruction on how to get around this?

Provide where?

> # For stage building, we cannot be sure the final unpack destination will have
> # xattr/fcaps support.  To be safe, we build stages without filecaps, but allow
> # filecaps to be turned back on @ next full world upgrade.  The ebuilds using
> # fcaps eclass will have more logic to safely fall back in case of missing
> # support.
> */* -filecaps
Comment 9 Marcus Comstedt 2021-01-26 07:50:44 UTC
> Provide where?

In the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'?  :-)

The point is that the wiki page (, which does an otherwise decent job of explaining how to use catalyst, fails to mention the need to include or read that file.  Rather, it suggests that only the spec file should be pulled from releng, and the portage_confdir statement commented out.

timkenhan did add a short note at the very end of the wiki page after making their comment here, to the effect that looking at the releng confdir as well could be a good idea, so that's a step in the right direction.  I think the specific issue with pam could be a candidate for the FAQ wikipage though.

The "portage_prefix" directive is not mentioned in either the manpage or the wiki page, which seems like a larger omission.