When I try to install s6 via Paludis, I get a pstree like this (until I ^C the install): [...] └─bash /usr/libexec/paludis/utils/dodoc -r examples └─bash /usr/libexec/paludis/utils/dodoc -r examples └─bash /usr/libexec/paludis/utils/dodoc -r ROOT s6-svscanboot └─bash /usr/libexec/paludis/utils/dodoc -r ROOT s6-svscanboot └─bash /usr/libexec/paludis/utils/dodoc -r README dev etc img mnt proc sy+ └─bash /usr/libexec/paludis/utils/dodoc -r README dev etc img mnt proc s+ └─bash /usr/libexec/paludis/utils/dodoc -r README procfs rofs rwfs sysf+ └─bash /usr/libexec/paludis/utils/dodoc -r README procfs rofs rwfs sys+ └─bash /usr/libexec/paludis/utils/dodoc -r README dev etc img mnt pro+ └─bash /usr/libexec/paludis/utils/dodoc -r README dev etc img mnt pr+ └─bash /usr/libexec/paludis/utils/dodoc -r README procfs rofs rwfs + └─bash /usr/libexec/paludis/utils/dodoc -r README procfs rofs rwfs+ [repeat for several hundred lines...] The root cause is that that "dodoc -r examples" command in the ebuild relies on undefined behaviour regarding cyclic symlinks. Portage's version of dodoc avoids the infinite recursion by having some very scary-looking symlink mangling code, whereas Paludis just does as it's told. I haven't tried pkgcore. I'm not entirely sure if this is a bug in the ebuild, the package manager, or the spec itself, or all 3. I've combed through PMS 5 and it doesn't specify how helper commands should handle symlinks when recursing, so *technically* both Portage/Paludis's interpretations are legal. (One behaviour is obviously useless, but I've already failed to convince its upstream of that...)
Wrong bug tracker.
Okay, that's two "not our problem" responses in a row. I'll give you the bug link so you can go tell them why they're wrong, and they can do likewise. Guess I'll just fix the ebuild to not be stupid and keep it in my local overlay then. Thanks for the help.
