sys-apps/man ebuild uses eutils' enewgroup to create a group for man. eutils in turn uses groupadd, which is provided by sys-apps/shadow. Unfortunately, man doesn't DEPEND on shadow, so it's possible (when building stages, mainly) to run into a problem where the emerge fails because groupadd isn't installed yet because the package order was not evaluated favorably. It also needs to RDEPEND on shadow, because if installing from cached binary packages (such as if you are making the packages as you go, so you can quickly build multiple stages), emerge *only* depends on RDEPEND and not DEPEND, so the same problem described above can occur if the package order is evaluated incorrectly. This should probably be fixed more upstream, i.e. eutils eclass should probably DEPEND/RDEPEND on shadow, to avoid problems with any similar ebuilds.
a proper system will have the user related binaries installed. release makes sure that shadow is included before other things so that stage building works.
Your logic for closing this bug is faulty. I've demonstrated that the ebuild has a clear compile-time dependency on shadow, as well as a runtime dependency when using binary packages. I've said that I have run into this problem in real-world situations (otherwise I wouldn't have filed this bug report). You are essentially saying that when Gentoo makes an official release, the release team manually goes through dependencies to ensure that your stages are built correctly (since it clearly can fail in an automatic build). That's great, but it's silly. By that logic, you might as well remove all DEPEND from all system ebuilds, because the release team will take care of the dependencies when building stages. This is an actual bug in the ebuild, and it would be nice for you guys to fix it (or fix the eclass) rather than dismissing it offhand.
man itself does not invoke anything from shadow. the enew{user,group} functions in eutils.eclass do, and how those work is transparent to ebuilds. any package using those functions are guaranteed the binaries will be available. your stage building process is flawed because it fails to fulfill that assumption.
If they were available, my emerge wouldn't have failed.
To clarify: they weren't available because portage didn't calculate dependencies correctly when using binary packages, because it uses only RDEPEND.
like i said, adjust your build. talk to the release team on irc if you dont know how.
What is there to adjust? It's a normal build of stages, done using normal procedures. The only difference is that if you use binary packages, emerge screws up because it doesn't evaluate DEPEND, only RDEPEND. This isn't a build problem with my stages, this is a problem with either emerge, or with RDEPEND in various ebuilds (lots of ebuilds have screwed up DEPEND/RDEPEND values, so this shouldn't be shocking).
funny because i dont see any failures with the Gentoo autobuilds that are constantly running like i said, if you want support, go ask releng on irc
Do the Gentoo autobuilds use binary packages if available? If not, you won't see a failure.
I didn't realize this was resolved.
same answer you've been given multiple times
(In reply to comment #5) > To clarify: they weren't available because portage didn't calculate > dependencies correctly when using binary packages, because it uses only > RDEPEND. FWIW, you can use --with-bdeps=y to make it pull in DEPEND for binary packages.
Zac, thanks for providing useful information. This should fix my problems.
*** Bug 284718 has been marked as a duplicate of this bug. ***
*** Bug 361753 has been marked as a duplicate of this bug. ***