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 3. 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)
Catalyst version: dev-util/catalyst-3.0.2
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.
Here is what releng sets temporarily, to be wiped/reset before the final packing: https://gitweb.gentoo.org/proj/releng.git/tree/releases/weekly/portage/stages/package.use/releng
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. :-)
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.
can we at least provide a clear instruction on how to get around this?
*** Bug 681136 has been marked as a duplicate of this bug. ***
(In reply to timkenhan from comment #6) > can we at least provide a clear instruction on how to get around this? Provide where? https://gitweb.gentoo.org/proj/releng.git/tree/releases/portage/stages/package.use/releng/no-filecaps > # 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
> 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 (https://wiki.gentoo.org/wiki/Catalyst), 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.
I bumped into this issue myself today on AMD64 so it's not just a PowerPC64 issue like the bug header suggests. Initially I worked around it by `chroot`-ing into the stage 3 build area and temporarily merging `libcap` without `pam` support. That worked well enough. Maybe in the steps for stage 3, there could be a list (specified in the profile perhaps?) of packages that are to be merged first with a specific set of USE flags. Alternatively, we put them in stage 2.
