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

[Sebastian Luther <SebastianLuther@gmx.de>]

Am 01.07.2011 08:12, schrieb Ciaran McCreesh:
> On Thu, 30 Jun 2011 20:48:46 +0200
> Sebastian Luther <SebastianLuther@gmx.de> wrote:
>>> 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.
> 
> Shouldn't be a workflow change. It's already policy to do a revbump if
> dependencies change.
> 

It is policy, but as you're probably aware of, it's not followed in may
cases, which in turn raises the question if people wouldn't prefer to
change the policy instead of their work flow (not that I would suggest
that).
Someone needs to ask them if you want that in EAPI5.

>>>> 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.
> 
> Part of the reason EAPI 3 dragged on for so long was that rather than
> reading the discussion, people would say "I've not read the entire
> thread, but it seems to me that ...", and then the entire discussion
> would have to be repeated all over again.

I think part of the problem here is that those things aren't written
down as a glep (or some similar document). Imo every change that leads
to a non trivial amount of discussion should be written down in such a
way. Otherwise it's hard for people that missed the original discussion
to catch up and those that took part in this discussion get frustrated
because they have to repeat themselves again and again.
This should be discussed in another thread if someone is interested.

> 
> If you're just looking for a summary, not details: say a user has
> cat/dep:1, cat/dep:2 and cat/dep:3 installed, and wants to uninstall
> cat/dep:1 and cat/dep:2. Say there's cat/pkg installed which has a dep
> upon cat/dep. Then there's no way for the package mangler to know
> which cat/dep slots are still 'needed', and which can be safely
> removed. Thus, to be safe, it has to assume that all three slots might
> be needed.
> 
Or you do it like portage does it and assume the package works with any
slot (the :* case) and if it doesn't, declare that a bug of the package.
Now giving ebuild devs the := operator allows them to say "the package
insist on the slot it was build against".

> Nearly all packages that dep upon a slotted dependent have one of two
> behaviours: they're ok with any slot that matches the rest of the spec
> (including switching at runtime), or they need the best slot that was
> present at install time. The former is :*, the latter :=.
> 
> There are a few perverse cases that don't fit these. Those need special
> fancy handling, and they're sufficiently fiddly that we shouldn't be
> holding up solving the large number easy cases to deal with one or two
> weird packages.
> 
Agreed.

>> 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)?
> 
> The problem is that every way of handling the "no operator" case is
> wrong for many real situations. You can assume either "any slot" or
> "best slot", both of which will allow packages to be removed unsafely,
> or you can assume "all slots", which is excessively paranoid for many
> packages.
> 
Do you see a way for the PM to decide which behavior it should use on
per case basis?
If yes, than having both operators makes sense.
If no, the PM has to decide on one of the behaviors anyways. Why not
specify which one that is (see above)?