Re: [gentoo-pms] Do we want an EAPI 5?

[Sebastian Luther]

Am 30.06.2011 19:22, schrieb Ciaran McCreesh:
> On Thu, 30 Jun 2011 14:43:22 +0200
> Sebastian Luther <SebastianLuther@×××.de> wrote:
>> Am 30.06.2011 12:31, schrieb Ciaran McCreesh:
>>> Should we start pushing for a reasonably quick EAPI 5? I'd see it as
>>> having:
>>>
>>> * The stuff that was left out of EAPI 3/4, which is to say :=/:*
>>>   dependencies, and the IUSE_IMPLICIT stuff (especially since right
>>>   now people are breaking the rules and implicitly using 'prefix'
>>> when they shouldn't, and the rules for (+) and (-) are largely
>>> useless without the stricter control).
>>
>> You shouldn't insist on these two as long as there is no portage
>> implementation.
>
> We need the IUSE_IMPLICIT stuff. The tree's already abusing use
> dependencies in a way that can't be handled correctly by a package
> mangler without it. We can't afford to continue having a broken tree
> because of a major screwup caused by the Portage people not thinking
> things through when they reduced the EAPI 4 feature set.
>
> Also, Zac's said that if the Council approves it, he'll have that
> feature done within a week.

In this case, ignore me on this one.

>
>> Are people (ebuild devs) really aware what introducing slot operator
>> deps would mean?
>> To make any use of them portage would have to stop updating installed
>> packages' metadata with ebuild metadata, which in turn means that
>> updating deps without revbump is going to cause problems for users.
>> I'm not saying that this is a bad thing, but it might not be what
>> people want.
>
> Portage's behaviour is already broken there -- think what happens when
> ebuilds get removed.
>

I know. I'm not opposed to this change, but the needed work flow change
for ebuild devs has to be communicated.

>> Could you please give a summary (or point me to one) of the discussion
>> about :=/:*?
>
> See the original EAPI 3 discussion. It's all there.
>
Yeah, the whole discussion is there, but not a summary. I don't have the
time to wade through all these mails.

>> Specifically, why do we need two of them instead of declaring one of
>> them the default. And if we want both, what does it mean to not
>> specify one of them?
>
> We need developers to be explicit. Neither behaviour is a sensible
> default, since both commonly occur in practice. Developers must
> carefully think through which they mean and then write the appropriate
> dependency. It can't be determined automatically, and it's not safe to
> assume that one particular behaviour is "probably" what's meant.
>

Isn't it desirable that different PMs handle the "no operator" case in
the same way (independently of the question of having one or both
operators available)?