Gentoo Logo
Gentoo Spaceship

Installation:
Gentoo Handbook
Installation Docs

Documentation:
Home
Listing
About Gentoo
Philosophy
Social Contract

Resources:
Bug Tracker
Developer List
Discussion Forums
Gentoo BitTorrents
Gentoo Linux Enhancement Proposals
IRC Channels
Mailing Lists
Mirrors
Name and Logo Guidelines
Online Package Database
Security Announcements
Staffing Needs
Supporting Vendors
View our CVS

Graphics:
Logos and themes
Icons
ScreenShots

Miscellaneous Resources:
Gentoo Linux Store
Gentoo-hosted projects
IBM dW/Intel article archive




List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Richard Freeman <rich0@g.o>
Subject: Re: Re: The fallacies of GLEP55
Date: Sat, 16 May 2009 11:34:14 -0400
Ciaran McCreesh wrote:
> 
> Had we gone with any of the other proposals a year ago, we'd be waiting
> a year every time a new change came along.

Only if that change prevented obtaining EAPI from wherever it was 
placed.  If you want to make the rule "EAPI=foo appears at the start of 
a new line at the top of the ebuild - EAPI is obtained from the first 
such line" then that would handle any situation except where the ebuild 
format can't have EAPI=foo at the start of a line.  Even XML could 
handle that (just put it in tags flanking it on different lines - since 
XML ignores newlines).  Even a binary file format could handle that if 
you just put <newline>EAPI=<eapi><newline> in the header.  The only 
thing it wouldn't handle is dynamically setting the EAPI, but I'm not 
aware of any proposals that do (except for splitting the EAPI into two 
parts - one part defines how to obtain the EAPI the other part does it - 
but that also works with EAPI=foo in the ebuild).

> 
> If the Council were not a fan of GLEP 55, they would have voted against
> it.
> 

Why?  If there is no reason to move forward with haste why not just 
leave it out there and see if somebody comes up with a better idea or 
see if circumstances change?  If the perception was that there were a 
pressing need for forward movement on this chances are that somebody 
would have proposed an alternative GLEP and the council would have just 
approved that instead.


Replies:
Re: Re: The fallacies of GLEP55
-- Ciaran McCreesh
References:
The fallacies of GLEP55
-- Patrick Lauer
Re: The fallacies of GLEP55
-- Ben de Groot
Re: The fallacies of GLEP55
-- Peter Alfredsen
Re: The fallacies of GLEP55
-- William Hubbs
Re: The fallacies of GLEP55
-- Ciaran McCreesh
Re: The fallacies of GLEP55
-- William Hubbs
Re: The fallacies of GLEP55
-- Ciaran McCreesh
Re: The fallacies of GLEP55
-- Tobias Klausmann
Re: The fallacies of GLEP55
-- Ciaran McCreesh
Re: The fallacies of GLEP55
-- Steven J Long
Re: Re: The fallacies of GLEP55
-- Ciaran McCreesh
Re: Re: The fallacies of GLEP55
-- Richard Freeman
Re: Re: The fallacies of GLEP55
-- Ciaran McCreesh
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: The fallacies of GLEP55
Next by thread:
Re: Re: The fallacies of GLEP55
Previous by date:
Re: The fallacies of GLEP55
Next by date:
Re: The fallacies of GLEP55


Updated Jun 17, 2009

Donate to support our development efforts.

Gentoo Centric Hosting: vr.org

VR Hosted

Tek Alchemy

Tek Alchemy

SevenL.net

SevenL.net

php|architect

php|architect

Copyright 2001-2007 Gentoo Foundation, Inc. Questions, Comments? Email www@gentoo.org.