1 |
On Fri, 22 Jun 2012 19:29:15 +0100 |
2 |
David Leverton <levertond@××××××××××.com> wrote: |
3 |
|
4 |
> Ian Stakenvicius wrote: |
5 |
> > Technically it could, but the issue here would be what you are going |
6 |
> > to do with a has_version check on an IUSE_RUNTIME dep -- the package |
7 |
> > should do filesystem-identical installs no matter what status of |
8 |
> > IUSE_RUNTIME flags, so whatever one would do with a has_version |
9 |
> > check would have to not change any part of the build or |
10 |
> > installation. |
11 |
> |
12 |
> In principle it would be used for more or less the same thing as it |
13 |
> would in a dependency, i.e. check whether the runtime-only |
14 |
> dependencies for that feature are satisfied - the difference being |
15 |
> that the package can specify arbitrary if-yes and if-no behaviours, |
16 |
> rather than just "fail the dependency resolution" or not. (Modulo |
17 |
> the problem being discussed in this subthread, that a "no" answer |
18 |
> isn't reliable.) |
19 |
> |
20 |
> For example, some tool used during the build might have a "slow" mode |
21 |
> that always works, and a "fast" mode that requires some other program |
22 |
> to be installed and that has to be requested explicitly. So the |
23 |
> package that uses the tool might want to do something like |
24 |
> |
25 |
> src_compile() { |
26 |
> if has_version dev-util/buildtool[fast]; then |
27 |
> buildtool --fast |
28 |
> else |
29 |
> buildtool |
30 |
> fi |
31 |
> } |
32 |
|
33 |
And that particular example should be perfectly valid, to be honest. |
34 |
There is just a little risk that fast mode wouldn't be used when it |
35 |
could. |
36 |
|
37 |
Of course, it's quite unlikely that such an option was actually based |
38 |
on runtime dep... |
39 |
|
40 |
-- |
41 |
Best regards, |
42 |
Michał Górny |