public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Road towards EAPI 3 main tree approval
Date: Sun, 30 Aug 2009 22:01:12 +0100	[thread overview]
Message-ID: <20090830220112.3a3620b8@snowcone> (raw)
In-Reply-To: <4A9ADB1E.6070801@gentoo.org>

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

On Sun, 30 Aug 2009 23:03:42 +0300
Petteri Räty <betelgeuse@gentoo.org> wrote:
> As far as I understand paludis already has the features implemented so
> maybe we could give EAPI 3 some field testing in some overlays to see
> how it works in practice from ebuild writer point of view.

The main issue with that is eclasses. Quite a few eclasses have
hard-coded lists of 'case ${EAPI:-0} in' lists. These would need to be
updated. So if you go this route:

> 20:01 < zmedico> Betelgeuse: I'd guess they could test it as
> EAPI=paludis-3_pre or something like that

then you'll have to clutter up the main tree with paludis-3_pre. And if
instead you call it '3', it means we have to guarantee we're not going
to make any last minute changes.

Also, as I recall there're two outstanding issues with EAPI 3 that
would need to be addressed by the Council.

First, there's the question of package.mask etc as directories. Some
people were after either doing a quicky EAPI 2.1 or reopening EAPI 3 to
allow that for the 10.0 profiles. I don't know whether that's still
considered worth doing or whether it's an EAPI 4 thing.

Second, there's the issue with 'nonfatal' and 'die' [1]. EAPI 3 as
originally worded made 'die' ignore 'nonfatal' (so that people wouldn't
have to modify all their eclass functions to take into account that
suddenly callers could override their dies), but some crappy wording in
the original spec (which has been addressed) meant that some people
didn't realise that, and would prefer it if we did that differently.

> Paludis does not recognize it atm but probably easy to get a new
> revision/version out:

Yup, can do that easily enough if there's interest once the above has
been addressed.

[1]: http://archives.gentoo.org/gentoo-dev/msg_358b12a494173ab82f3e7d1b2b6b5bf9.xml

-- 
Ciaran McCreesh

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

      reply	other threads:[~2009-08-30 15:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-30 20:03 [gentoo-dev] Road towards EAPI 3 main tree approval Petteri Räty
2009-08-30 21:01 ` Ciaran McCreesh [this message]

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=20090830220112.3a3620b8@snowcone \
    --to=ciaran.mccreesh@googlemail.com \
    --cc=gentoo-dev@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