Duncan wrote:
> Donnie Berkholz <[EMAIL PROTECTED]> posted
> [EMAIL PROTECTED], excerpted below, on Sun, 16 Dec 2007
> 12:49:13 -0800:
>
>> I think it's valuable to show the flags that actually need to be changed
>> rather than a full list of all required flags.
>
> ++
>
I messed about on some
Hello,
attaching the GLEP.
most current version:
http://dev.gentoo.org/~peper/glep-0055.html
http://dev.gentoo.org/~peper/glep-0055.txt
--
Best Regards,
Piotr Jaroszyński
GLEP: 55
Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Version: $Revision: $
Last-Modified: $Date: $
Author: Piotr Jaroszy
On 2007/12/17, Piotr Jaroszyński <[EMAIL PROTECTED]> wrote:
> http://dev.gentoo.org/~peper/glep-0055.html
> * Possibility to extend the versioning rules in an EAPI, and to
> use them immediately in the Gentoo tree. For example, addition of
> the scm suffix - GLEP54 [1].
...
> Currently ebuilds
On Tue, 18 Dec 2007 00:40:05 +0100
Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:
> - metadata/cache: latest PMS i've found (2007/07/08 on dev.g.o/~spb)
> says it contains some "/-" files. If a
> package manager assumes the "" syntax is the one defined in
> the said PMS, and you extend thi
Piotr Jaroszyński wrote:
> Hello,
>
> attaching the GLEP.
>
> most current version:
> http://dev.gentoo.org/~peper/glep-0055.html
> http://dev.gentoo.org/~peper/glep-0055.txt
>
>
> Abstract
>
> This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds
> (for example, foo-1.
On Mon, 17 Dec 2007 17:10:46 -0700
Joe Peterson <[EMAIL PROTECTED]> wrote:
> I probably missed some of the stuff leading up to this GLEP, but what
> is the problem with having the EAPI in the file and determining it by
> looking at the file contents?
Motivation, second bullet point:
| Possibility
Ciaran McCreesh wrote:
>> I imagine a lot of people do things now like 'find . -name "*.ebuild"
>> | xargs grep ...'. Not that they could not change their habbits, but
>> forgetting to add a more complex matching rule could lead to errors
>> here.
>
> -name '*.ebuild*' isn't exactly much more com
On 2007/12/18, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> On Mon, 17 Dec 2007 17:10:46 -0700
> Joe Peterson <[EMAIL PROTECTED]> wrote:
> > I probably missed some of the stuff leading up to this GLEP, but
> > what is the problem with having the EAPI in the file and
> > determining it by looking a
On Mon, 17 Dec 2007 17:30:50 -0700
Joe Peterson <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> >> I imagine a lot of people do things now like 'find . -name
> >> "*.ebuild" | xargs grep ...'. Not that they could not change
> >> their habbits, but forgetting to add a more complex matching ru
On Tue, 18 Dec 2007 01:36:51 +0100
Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:
> Why can't it be in the file but readable without sourcing? For
> instance, it could be mandatory that EAPI=X, if present, must be the
> first non-blank and non-comment line of the ebuild (and it would then
>
On Tuesday 18 December 2007 01:36:51 Thomas de Grenier de Latour wrote:
> Why can't it be in the file but readable without sourcing? For instance,
> it could be mandatory that EAPI=X, if present, must be the first
> non-blank and non-comment line of the ebuild (and it would then be
> checked after
Ciaran McCreesh wrote:
> On Tue, 18 Dec 2007 01:36:51 +0100
> Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:
>> Why can't it be in the file but readable without sourcing? For
>> instance, it could be mandatory that EAPI=X, if present, must be the
>> first non-blank and non-comment line of t
On Mon, 17 Dec 2007 18:05:23 -0700
Joe Peterson <[EMAIL PROTECTED]> wrote:
> This option is worth thinking about more - there may be satisfactory
> ways to mediate the issues. It is certainly more elegant
Introducing new parse and format requirements upon bash files is most
definitely not elegant
Ciaran McCreesh wrote:
> On Mon, 17 Dec 2007 18:05:23 -0700
> Joe Peterson <[EMAIL PROTECTED]> wrote:
>> This option is worth thinking about more - there may be satisfactory
>> ways to mediate the issues. It is certainly more elegant
>
> Introducing new parse and format requirements upon bash fil
On Mon, 17 Dec 2007 23:20:01 +0100
Piotr Jaroszyński <[EMAIL PROTECTED]> wrote:
> Hello,
>
> attaching the GLEP.
How does this chord with eclasses that set EAPI, instead of ebuilds?
Last I read was that EAPI-set-by-eclass was close to being ratified.
Kind regards,
JeR
--
[EMAIL PROTECTED]
On Tue, 18 Dec 2007 05:41:45 +0100
Jeroen Roovers <[EMAIL PROTECTED]> wrote:
> How does this chord with eclasses that set EAPI, instead of ebuilds?
> Last I read was that EAPI-set-by-eclass was close to being ratified.
Read where? So far as I'm aware, everyone's been saying "don't set EAPI
in an e
On Tue, 18 Dec 2007 04:46:35 +
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> On Tue, 18 Dec 2007 05:41:45 +0100
> Jeroen Roovers <[EMAIL PROTECTED]> wrote:
> > How does this chord with eclasses that set EAPI, instead of ebuilds?
> > Last I read was that EAPI-set-by-eclass was close to being rat
On Tue, 18 Dec 2007 06:27:02 +0100
Jeroen Roovers <[EMAIL PROTECTED]> wrote:
> On this mailing list, in the "EAPI placement" thread.
OK, it would seem that discussion has now died in favour of
forbidding eclasses setting EAPI altogether. But now, if
pkg-5.ebuild-zillion doesn't set an EAPI variab
> On Tue, 18 Dec 2007, Ciaran McCreesh wrote:
> | Possibility to extend the behaviour of inherit and add new global
> | scope functions (as a result of not sourcing ebuilds with
> | unsupported EAPI).
It seems to me that this will inconvenience the users, in order to
solve a technical problem
On Tue, 18 Dec 2007 08:17:49 +0100
Ulrich Mueller <[EMAIL PROTECTED]> wrote:
> > On Tue, 18 Dec 2007, Ciaran McCreesh wrote:
> > | Possibility to extend the behaviour of inherit and add new global
> > | scope functions (as a result of not sourcing ebuilds with
> > | unsupported EAPI).
>
> It s
20 matches
Mail list logo
