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