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

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]

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.

> >> 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.

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.

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.

> 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.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]