The devmanual currently have this paragraph about the system dependencies: All packages have an implicit compile-time and runtime dependency upon the entire system target. It is therefore not necessary, nor advisable, to specify dependencies upon gcc, libc and so on, except where specific versions or packages (for example, glibc over uclibc) are required Although this is mostly correct, there are a few cases where this creates little problems. For instance, emerge -e world (or the equivalents for paludis and pkgcore) does not build system before the rest, which means that if you have a broken sys-libs/zlib (like I do right now) and you're running "emerge -e world", some packages are moved before zlib itself and fails to build (current list: exiv2, cvsps, csup and liblbxutil). In my opinion, system libraries should be avoided when: - they are totally implicit (virtual/libc, sys-devel/gcc, sys-devel/binutils); - they can create circular dependencies (sys-apps/shadow); - they create difficulties to alternative profiles (app-arch/tar, sys-apps/findutils), although these can be fixed properly by creating proper virtuals.
Care to suggest a patch against /var/svnroot/devmanual/trunk
I don't see a documentation issue here. The same problem you listed here could happen if I had a broken gcc, glibc, tar, gzip, binutils, etc. Please reopen if you can make the issue with devmanual clearer.
QA team has to decide on _exactly_ what the practise should be in regard to system packages, and make that well cleared. QA team didn't address this in fourteen months, it's not just a issue with the devmanual per se, but it's still well an issue.
It's quite simple. Only specify system things as deps if you have a good reason for doing so.
(In reply to comment #3) > QA team has to decide on _exactly_ what the practise should be in regard to > system packages, and make that well cleared. Which part of this is not clear? http://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency The problem you listed here is a problem with the dependency resolver if anything. System packages should not be listed unless there is a very very good reason. Just because you had a broken zlib package doesn't mean that the documentation or QA's policies are wrong. The same exact issue could come up when your gcc is completely busted. How are we supposed to address that situation?
And again, we go back to closed, as the documentation is pretty clear for when you should add system packages into dependencies (unless you can point out how it isn't) Thanks
