1 |
On Tue, 08 Aug 2006 00:54:29 +0100, |
2 |
Paul Bredbury <brebs@××××.com> wrote: |
3 |
|
4 |
> > 3. package has not been built. (?) |
5 |
> |
6 |
> The answer is False, not unknown, as I keep saying. |
7 |
|
8 |
You keep trying to reason based on a function name ("built_with_use"). |
9 |
>From a litteral english point of view, i would agree with you that a |
10 |
package which was not built at all is not built with any particular |
11 |
flag. But, see, this is just a function name, and that's not what |
12 |
defines its expected semantics. There is nothing one can "prove" by |
13 |
logic here¹, but just a choice to make. The only thing which matters is |
14 |
what devs think is the most convenient for their needs, and it is clear |
15 |
from this discussion that they all prefer a function which is only |
16 |
defined for installed packages (and dies when missused, so that |
17 |
missuses are detected and fixed). Maybe a better name would have been: |
18 |
was_the_installed_package_foo_built_with_the_flag_bar_comma_where_foo_is_first_argument_and_bar_the_second_one_question_mark |
19 |
...but that's a bit too long, and this kind of details should rather go |
20 |
to the documentation. |
21 |
|
22 |
|
23 |
> There, you'll meet "conditional probability". If A is False, then the |
24 |
> probability of B, given that B *depends* on A, is zero. |
25 |
|
26 |
Take probabilities of a coin flip, apply them to a dice, and you can |
27 |
"prove" it always falls on tails, since it can't fall on heads. Or |
28 |
maybe it's the opposite, oh well... |
29 |
|
30 |
Again, reasoning out of the definition domain gives nothing meaningful. |
31 |
For "build_with_use", it has been decided that the definition domain |
32 |
would be installed packages. Deal with it. |
33 |
|
34 |
|
35 |
---- |
36 |
¹ the only thing one really bored could try to prove is that the actual |
37 |
implementation of the function fits its expected semantics. But that's |
38 |
a different topic. |
39 |
|
40 |
|
41 |
-- |
42 |
TGL. |
43 |
|
44 |
-- |
45 |
gentoo-portage-dev@g.o mailing list |