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

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

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

On Fri, 01 Jul 2011 09:45:34 +0200
Sebastian Luther <SebastianLuther@gmx.de> wrote:
> >> 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).

Anyone not following the policy is already breaking things, and we
can't switch to the "use the tree ebuild" behaviour since it doesn't
work when ebuilds get removed. All we're doing is making an existing
bug more visible.

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

It's not worth it. It's a huge amount of work to summarise every
incorrect argument and false lead. It's not done by official standards
bodies, who have far more resources than we do, so what you're asking
for is just obstructionism and red tape.

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

Can't. Right now there's no way for packages to specify those kinds of
dependencies correctly. Assuming :* just isn't safe, and doesn't match
the historical meaning of lack-of-slot dependencies.

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

The package mangler has to be told explicitly. It can't work it out
itself.

> 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)?

Having both operators provides a way of checking that developers have
explicitly confirmed which behaviour they mean. Without them, we don't
know whether no operator means "whichever default we decide", or
whether it means "I didn't realise that this dep has slots now".

-- 
Ciaran McCreesh

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