public inbox for gentoo-pms@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
To: gentoo-pms@lists.gentoo.org
Subject: Re: [gentoo-pms] Do we want an EAPI 5?
Date: Thu, 30 Jun 2011 18:22:58 +0100	[thread overview]
Message-ID: <20110630182258.5fb6ab5f@googlemail.com> (raw)
In-Reply-To: <4E0C6F6A.9090807@gmx.de>

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

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

> 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

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

  reply	other threads:[~2011-06-30 17:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-30 10:31 [gentoo-pms] Do we want an EAPI 5? Ciaran McCreesh
2011-06-30 12:43 ` Sebastian Luther
2011-06-30 17:22   ` Ciaran McCreesh [this message]
2011-06-30 18:48     ` Sebastian Luther
2011-07-01  6:12       ` Ciaran McCreesh
2011-07-01  7:45         ` Sebastian Luther
2011-07-01  8:09           ` Ciaran McCreesh
2011-07-01  8:54             ` Sebastian Luther
2011-07-01  9:09               ` Ciaran McCreesh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110630182258.5fb6ab5f@googlemail.com \
    --to=ciaran.mccreesh@googlemail.com \
    --cc=gentoo-pms@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox