[gentoo-dev] Re: Dependencies that're available at pkg_*inst

[Duncan]

Donnie Berkholz <dberkholz@g.o> posted
20080421051727.GA10765@comet, 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@l.g.o mailing list