From: Andrew Gaffney <agaffney@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Date: Wed, 25 Feb 2009 16:19:15 -0600 [thread overview]
Message-ID: <49A5C3E3.1090209@gentoo.org> (raw)
In-Reply-To: <20090225124951.GD3506@hrair>
Brian Harring wrote:
>
> 4) eapi as a function; instead of "EAPI=1", do "eapi 1", required as
> the first statement (simplest way).
> pros:
> - global scope changes can occur (inherit mechanism changes
> included).
> - expanding on the first, auto inherits (pkg level) are possible-
> effectively when eapi gets invoked the manager is in control and
> can do whatever is desired setting up the env wise.
> - bash version requirements can be leveled (bash parses as it goes,
> meaning that essentially it won't parse what follows 'eapi 2' till
> that command statement finishes)
> - fits w/ the existing semantics nicely enough.
> cons:
> - mangling the version rules for pkgs still isn't possible; no -scm.
> Arguable if -scm is even desired, but being explicit about it not
> covering this.
> - transition is slightly icky; basically one of the following is
> required-
> a) for EAPI>=2, do 'eapi 3 || die "upgrade your manager"'. Reason
> for this is that current managers obviously lack an eapi function,
> to make managers available *now* blow up the || die is required.
> This solution can be deployed now, no transition required although
> at some point stating "eapi is required retroactively for all
> eapis" would be wise to eliminate the need for the || die (cut
> support basically for old managers)
> b) bashrc trickery, defines an eapi if it's unset. Said eapi
> function exports EAPI=$1, optionally triggering a die if the eapi
> isn't 0,1,2 (since any later eapi would require a manager upgrade
> which would also have the eapi function).
>
> Personally, if g54 is ixnayed #4 I tend to think is the best option
> out there- if g54 is forced in, g55 (or at least something that
> adjusts the extension to make it invisible to current managers) is
> required.
>
> Commentary? Tend to think #4 is the most aesthetically pleasing to
> folk, but who knows...
> ~harring
I really like this idea, but nobody else seems to have commented on it.
--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Genkernel + Release Engineering Lead
next prev parent reply other threads:[~2009-02-25 22:19 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-24 22:21 [gentoo-dev] Collecting opinions about GLEP 55 and alternatives Petteri Räty
2009-02-24 22:49 ` Ferris McCormick
2009-02-24 23:48 ` [gentoo-dev] " Ryan Hill
2009-02-25 0:38 ` [gentoo-dev] " Richard Freeman
2009-02-25 2:40 ` Jeremy Olexa
2009-02-25 3:53 ` Dawid Węgliński
2009-02-25 4:32 ` Alistair Bush
2009-02-25 6:46 ` Alec Warner
2009-02-25 6:49 ` Jeroen Roovers
2009-02-25 6:53 ` Ulrich Mueller
2009-02-25 21:00 ` Joe Peterson
2009-02-25 8:16 ` Alexis Ballier
2009-02-25 10:05 ` Tobias Klausmann
2009-02-25 10:34 ` Peter Alfredsen
2009-02-25 10:59 ` Michael Haubenwallner
2009-02-25 11:18 ` Mike Auty
2009-02-25 11:57 ` Jim Ramsay
2009-02-25 12:49 ` Brian Harring
2009-02-25 22:19 ` Andrew Gaffney [this message]
2009-02-25 23:03 ` [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives) Ciaran McCreesh
2009-02-26 0:02 ` Brian Harring
2009-02-26 0:11 ` Ciaran McCreesh
2009-02-26 0:24 ` Brian Harring
2009-02-26 0:32 ` Ciaran McCreesh
2009-02-26 0:43 ` Jorge Manuel B. S. Vicetto
2009-02-26 0:51 ` Ciaran McCreesh
2009-02-26 11:07 ` Petteri Räty
2009-02-25 14:33 ` [gentoo-dev] Collecting opinions about GLEP 55 and alternatives Robert Buchholz
2009-02-25 19:03 ` Thomas Anderson
2009-02-25 21:09 ` Josh Saddler
2009-02-26 2:13 ` Ravi Pinjala
2009-02-26 3:13 ` Kumba
2009-02-28 20:52 ` Kumba
2009-02-26 5:36 ` Zac Medico
2009-02-26 18:07 ` Ciaran McCreesh
2009-02-26 18:20 ` Ciaran McCreesh
2009-02-26 18:47 ` Nirbheek Chauhan
2009-02-26 18:56 ` Ciaran McCreesh
2009-02-26 19:16 ` Nirbheek Chauhan
2009-02-26 19:24 ` Ciaran McCreesh
2009-02-27 9:27 ` Caleb Cushing
2009-02-27 10:52 ` Rémi Cardona
2009-02-28 10:56 ` Peter Volkov
2009-02-28 12:25 ` Fernando J. Pereda
2009-02-28 19:39 ` Robert Bridge
2009-02-28 19:46 ` Ciaran McCreesh
2009-03-02 7:31 ` [gentoo-dev] " Christian Faulhammer
2009-03-02 8:33 ` Tiziano Müller
2009-03-02 21:23 ` [gentoo-dev] " Thilo Bangert
2009-03-09 13:01 ` Jacob Floyd
2009-03-09 15:54 ` [gentoo-dev] " Duncan
2009-03-09 19:54 ` Richard Freeman
2009-03-10 6:18 ` Duncan
2009-03-10 15:58 ` Christian Faulhammer
2009-03-10 21:11 ` Santiago M. Mola
2009-03-10 8:53 ` [gentoo-dev] " Michael Haubenwallner
2009-03-12 17:18 ` Alistair Bush
2009-03-13 10:29 ` Michael Haubenwallner
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=49A5C3E3.1090209@gentoo.org \
--to=agaffney@gentoo.org \
--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