On Thu, 30 Jun 2011 14:43:22 +0200 Sebastian Luther 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. > 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. > 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. > 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. -- Ciaran McCreesh