On Tue, Sep 18, 2012 at 10:25:51AM +0200, Micha?? G??rny wrote:
> > test depends: to specifically mark those dependencies that are only
> > needed for when the pkg is being tested; effectively ephemeral
> > build/run time depends that go away once testing is completed.
> 
> Does that mean that USE=test is going away somehow?

If you think it through, a test use flag still is needed in the cases 
where the rdep itself would change if test was enabled; such a source 
is fairy rare, but not always just someone being moronic- certain 
cases to do testing, the tests need to reach in fairly deeply and 
recompilation for compile vs test isn't exposed.


> Also, could you please stop spreading FUD with your examples?

It's not FUD; it's rendered deps, and a demonstration of how they 
collapse down naturally on their own regardless of how you generate 
them.

Quite frankly, it's a fairly effective demonstration in my views, but 
so it goes.

> A quick
> glance shows that what you have expanded there, a fairly reasonable
> Gentoo dev will solve using:
>
> RDEPEND="[common depends]"
> DEPEND="${RDEPEND}
>     [build only depends]"

from diffball (under current EAPIs)

"""
RDEPEND=">=sys-libs/zlib-1.1.4
        >=app-arch/bzip2-1.0.2
        app-arch/xz-utils"
DEPEND="${RDEPEND}
        virtual/pkgconfig"
"""

becomes the following under the proposal:

"""
DEPENDENCIES=">=sys-libs/zlib-1.1.4
        >=app-arch/bzip2-1.0.2
        app-arch/xz-utils"
        dep:build? ( virtual/pkgconfig )"
"""

Suspect I may add that to the doc; it's a good example of the ground 
level simple gains for devs inherent in the proposal- thanks for 
helping improve it.


> So if you really want to show some advantages, please compare it with
> *real* code.

I think I'll take the risk, and assume people capable of discussing 
DEPENDENCIES and vaguely knowledgable in the ebuild format will be 
able to understand how their ebuilds will change; thus I'll skip that 
request of yours.


A productive suggestion for you; you should go looking through the 
tree finding cases where DEPENENCIES is a regression in form at the 
shell level, or rendered deps level.

Should you manage to find something that's not contrived or 
intentionally cracktastic, I expect people would be interested.

~harring

Reply via email to