1 |
Am 30.06.2011 19:22, schrieb Ciaran McCreesh: |
2 |
> On Thu, 30 Jun 2011 14:43:22 +0200 |
3 |
> Sebastian Luther <SebastianLuther@×××.de> wrote: |
4 |
>> Am 30.06.2011 12:31, schrieb Ciaran McCreesh: |
5 |
>>> Should we start pushing for a reasonably quick EAPI 5? I'd see it as |
6 |
>>> having: |
7 |
>>> |
8 |
>>> * The stuff that was left out of EAPI 3/4, which is to say :=/:* |
9 |
>>> dependencies, and the IUSE_IMPLICIT stuff (especially since right |
10 |
>>> now people are breaking the rules and implicitly using 'prefix' |
11 |
>>> when they shouldn't, and the rules for (+) and (-) are largely |
12 |
>>> useless without the stricter control). |
13 |
>> |
14 |
>> You shouldn't insist on these two as long as there is no portage |
15 |
>> implementation. |
16 |
> |
17 |
> We need the IUSE_IMPLICIT stuff. The tree's already abusing use |
18 |
> dependencies in a way that can't be handled correctly by a package |
19 |
> mangler without it. We can't afford to continue having a broken tree |
20 |
> because of a major screwup caused by the Portage people not thinking |
21 |
> things through when they reduced the EAPI 4 feature set. |
22 |
> |
23 |
> Also, Zac's said that if the Council approves it, he'll have that |
24 |
> feature done within a week. |
25 |
|
26 |
In this case, ignore me on this one. |
27 |
|
28 |
> |
29 |
>> Are people (ebuild devs) really aware what introducing slot operator |
30 |
>> deps would mean? |
31 |
>> To make any use of them portage would have to stop updating installed |
32 |
>> packages' metadata with ebuild metadata, which in turn means that |
33 |
>> updating deps without revbump is going to cause problems for users. |
34 |
>> I'm not saying that this is a bad thing, but it might not be what |
35 |
>> people want. |
36 |
> |
37 |
> Portage's behaviour is already broken there -- think what happens when |
38 |
> ebuilds get removed. |
39 |
> |
40 |
|
41 |
I know. I'm not opposed to this change, but the needed work flow change |
42 |
for ebuild devs has to be communicated. |
43 |
|
44 |
>> Could you please give a summary (or point me to one) of the discussion |
45 |
>> about :=/:*? |
46 |
> |
47 |
> See the original EAPI 3 discussion. It's all there. |
48 |
> |
49 |
Yeah, the whole discussion is there, but not a summary. I don't have the |
50 |
time to wade through all these mails. |
51 |
|
52 |
>> Specifically, why do we need two of them instead of declaring one of |
53 |
>> them the default. And if we want both, what does it mean to not |
54 |
>> specify one of them? |
55 |
> |
56 |
> We need developers to be explicit. Neither behaviour is a sensible |
57 |
> default, since both commonly occur in practice. Developers must |
58 |
> carefully think through which they mean and then write the appropriate |
59 |
> dependency. It can't be determined automatically, and it's not safe to |
60 |
> assume that one particular behaviour is "probably" what's meant. |
61 |
> |
62 |
|
63 |
Isn't it desirable that different PMs handle the "no operator" case in |
64 |
the same way (independently of the question of having one or both |
65 |
operators available)? |