public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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



  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