Donnie Berkholz <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 20 Apr 2008 22:17:27 -0700:
> I guess the RDEPEND+DEPEND case would save an ebuild dev the work of > specifying the COMMON_DEPEND list, but other than that, I can't think of > any benefits. It would force both RDEPEND and DEPEND to be installed for > binpkgs, which sucks. If I read the original proposal correctly, it's not proposing a simple +, that BOTH RDEPEND and DEPEND be guaranteed installed at pkg_*inst, IOW by set theory, not the UNION of the two sets, but the INTERSECTION of the two sets, that is, packages that appear in both lists at once, not those appearing in one XOR the other. Thus a COMMON_DEPEND would still be useful as it would be the list appearing in both (thus effectively the list necessary for pkg_*inst, same as the OR case). Both lists could still exclusively include packages, and packages not listed in DEPEND only would not have to be installed for binpkgs. So it's not OR vs AND, but OR vs INTERSECTION. As I stated in my other post, RDEPEND alone can't be used without breaking things. That applies to binary package installation as well, where DEPEND along can't be used either as that would require installation of unwanted packages. Thus, the OR case doesn't seem to work for binary installation at all, since neither RDEPEND nor DEPEND can be relied upon alone, and the OR case proposes requiring at least one complete set of the two be installed. Thus, for current EAPIs, the INTERSECTION alternative is the only possibly working alternative if we are not to break binary package support and not force full DEPEND installation on binary targets. It's not ideal as it'll potentially force unwanted and otherwise unnecessary package installation on both the build-host and the binary target, due to fact that it forces pkg_*inst dependencies into both DEPEND and RDEPEND, but IMO it's better than forcing the whole set of DEPENDs to be installed on binary targets, which would be the only working alternative in the OR case above. As others have said, this is certainly a good candidate for future EAPI change, but it's not future EAPIs under current discussion, so that fact doesn't help the current discussion. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
