1 |
> On Jun 17, 2016, at 11:48 PM, Jonathan Callen <jcallen@g.o> wrote: |
2 |
> |
3 |
>> On 06/17/2016 06:22 PM, Ian Stakenvicius wrote: |
4 |
>>> On 17/06/16 06:17 PM, Ian Stakenvicius wrote: |
5 |
>>>> On 17/06/16 05:22 PM, Michał Górny wrote: |
6 |
>>>> On Sat, 18 Jun 2016 00:06:10 +0300 |
7 |
>>>> Andrew Savchenko <bircoph@g.o> wrote: |
8 |
>>>> |
9 |
>>>>>> On Fri, 17 Jun 2016 19:42:18 +0200 Michał Górny wrote: |
10 |
>>>>>> Hello, |
11 |
>>>>>> |
12 |
>>>>>> Since this is a major issue involving a lot of packages, and it needs |
13 |
>>>>>> to be fixed *quickly*, I'm forwarding the new check results to |
14 |
>>>>>> gentoo-dev. |
15 |
>>>>>> |
16 |
>>>>>> If the below list contains your package, please fix it ASAP. I will |
17 |
>>>>>> file bugs for the remaining packages then. |
18 |
>>>>>> |
19 |
>>>>>> Long story short, using := operator inside || () conditional blocks is |
20 |
>>>>>> completely forbidden and triggers random misbehavior inside package |
21 |
>>>>>> managers (Portage doesn't do exactly what you think it does). |
22 |
>>>>> |
23 |
>>>>> Please explain in more details why this is forbidden. man 5 ebuild |
24 |
>>>>> contains nothing about this, I can't find anything in PMS also. If |
25 |
>>>>> package manager misbehaves this doesn't automatically imply that |
26 |
>>>>> ebuilds are broken (and not PM). |
27 |
>>>> |
28 |
>>>> It was explained already. PMS doesn't permit it. It doesn't make *any* |
29 |
>>>> sense, so the author didn't even bother explicitly saying it's |
30 |
>>>> forbidden. Package manager can't not misbehave if something can't be |
31 |
>>>> implemented. |
32 |
>>> |
33 |
>>> Where does PMS not permit it?? |
34 |
>>> |
35 |
>>> 8.2: [...] |
36 |
>>> An any-of group, which consists of the string ||, followed by |
37 |
>>> whitespace, followed by an open parenthesis, followed by whitespace, |
38 |
>>> followed by zero or more of (a dependency item of any kind followed by |
39 |
>>> whitespace), followed by a close parenthesis. |
40 |
>>> |
41 |
>>> |
42 |
>>> "dependency item of any kind" would certainly include atoms with slot |
43 |
>>> operators. |
44 |
>>> |
45 |
>>> |
46 |
>>> There is also no caveat at all in 8.2.3 that excludes slot operators, |
47 |
>>> and 8.2.6.3 also contains no caveat or exclusion of slot operators |
48 |
>>> from any-of groups. |
49 |
>>> |
50 |
>>> |
51 |
>>> Using slot operators within OR deps was intended when EAPI5 was |
52 |
>>> introduced. If Portage and other PMs don't handle it well or properly |
53 |
>>> then they should be fixed, and perhaps the spec should be refined in |
54 |
>>> EAPI7, but that doesn't mean banning it now. |
55 |
>> |
56 |
>> |
57 |
>> Now, one thing that *is* banned is the use of :[SLOT]/[Sub-Slot] |
58 |
>> values in ebuilds, as per PMS s.8.2.6.3 -- I know there's plenty of |
59 |
>> ebuilds that are doing that, including in virtuals. |
60 |
> |
61 |
> No, the specific syntax that is banned is ":0/0=" (that is, both a |
62 |
> subslot and a slot operator). It is perfectly legal to depend on ":0/0" |
63 |
> or on ":0=", but not on ":0/0=". |
64 |
> |
65 |
|
66 |
Ah, thank you for that clarification -- I didn't catch the language was specifying the subslot as coming before the equal sign. |
67 |
|
68 |
Well, good that this would be banned given it wouldn't make any sense (triggering a rebuild when the subslot changes, while tying something to a single slot/subslot value, would never do anything) |