On Sat, 17 Jan 2009 16:41:25 +0100 Thomas Sachau <to...@gentoo.org> wrote:
> Marius Mauch schrieb: > > It's strongly recommended to set both explicitly as the behavior > > could change in future EAPI versions, and to ensure that you > > actually think about which deps are build deps and which are > > runtime deps. Also there is nothing wrong with policies being > > stricter than the underlying spec. > > If i want to use some future EAPI (give me some reasons, why this > should be changed there by default), i should think about it. If nothing else, dropping the implicit assignment would remove one special case to handle in the PM (and I hope that everyone agrees that special cases should generally be avoided). In the past there have also been some issues due to the interaction between the implicit setting of RDEPEND and eclasses (long fixed, but shows that there is a bit more involved than might obvious). > But most ebuilds will stay with the default. I do think about > runtime deps and build deps. If you do that's good, but that doesn't mean everyone else does. Consider looking at an ebuild for a package you're not familiar with that doesn't set RDEPEND. Could mean that the author was just too lazy to add a RDEPEND="$DEPEND" statement and that all deps are needed for build and runtime, or that he completely forgot to think about runtime deps. There is no way to know (without asking him) if the implicit RDEPEND is actually intended or not. > In my eyes, this is similar to src_unpack and src_compile. They > have defaults, noone specifies the defaults, even if they are changed > in some EAPI. Sure, but the key difference is that the defaults for those are fixed. You would have a point if the default src_compile would vary based on what other phase functions the ebuild defines, but that's not the case. Marius
