Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs

[Marius Mauch]

On Sat, 17 Jan 2009 16:41:25 +0100
Thomas Sachau <tommy@g.o> 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