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