On 06:33 Sat 19 Apr , Ciaran McCreesh wrote: > On Fri, 18 Apr 2008 22:27:21 -0700 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > My interpretation is pkg_* counts as runtime (I can imagine a package > > wanting to run itself at this point), so packages in RDEPEND should > > be usable at that point. > > Which would be fine, except it makes the tree unusable.
Isn't this part of the first situation offered (RDEPEND+DEPEND, rather than RDEPEND|DEPEND)? I don't think I understand the difference between the effects of these two options. Could you describe a scenario where one would make things possible and the other wouldn't? Here's my attempt from an ebuild dev's POV, not from an ebuild dependency POV: The way I'm thinking, the RDEPEND|DEPEND case means an ebuild developer would have no idea which list would be used, so you'd have something like COMMON_DEPEND to describe the pkg_*-used dependency, which would be in both RDEPEND and DEPEND. This would allow both RDEPEND and DEPEND to have unique dependencies, which seems like it could be beneficial. It would probably require fixing the tree for packages that currently assume RDEPEND will be available, although I don't expect that many packages will have unique RDEPEND settings (mainly binaries). 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. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
