Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-22 Thread Ciaran McCreesh
On Sat, 22 Dec 2007 10:12:51 -0500 Richard Freeman <[EMAIL PROTECTED]> wrote: > > And then you are stuck FOREVER into defining EAPI as a variable. > > And with the proposed GLEP you are stuck FOREVER into defining EAPI as > part of the filename. What's the difference? No you aren't. That is the

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-22 Thread Zhang Le
Fernando J. Pereda wrote: > On Sat, Dec 22, 2007 at 06:01:04PM +0800, Zhang Le wrote: >>> Your algorithm: >>> >>> Does not work for existing ebuilds that have implicit EAPI 0. >> That's obvious. If no suffix, just treat it as EAPI 0. >> I thought I don't need to say this explicitly. > > '# Copyrig

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-22 Thread Zhang Le
Richard Freeman wrote: > Fernando J. Pereda wrote: >> On Sat, Dec 22, 2007 at 06:01:04PM +0800, Zhang Le wrote: >>> All could be get before sourcing. >>> I know you'd say people will use all syntaxes to define. But how many are >>> there? EAPI=1, EAPI="1" these are the two ways currently used in tr

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-22 Thread Richard Freeman
Fernando J. Pereda wrote: > On Sat, Dec 22, 2007 at 06:01:04PM +0800, Zhang Le wrote: >> All could be get before sourcing. >> I know you'd say people will use all syntaxes to define. But how many are >> there? EAPI=1, EAPI="1" these are the two ways currently used in tree. >> A simple qgrep can sho

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-22 Thread Fernando J. Pereda
On Sat, Dec 22, 2007 at 06:01:04PM +0800, Zhang Le wrote: > > > > Your algorithm: > > > > Does not work for existing ebuilds that have implicit EAPI 0. > > That's obvious. If no suffix, just treat it as EAPI 0. > I thought I don't need to say this explicitly. '# Copyright 1999-2007 Gentoo Found

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-22 Thread Zhang Le
Ciaran McCreesh wrote: > On Sat, 22 Dec 2007 16:55:50 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> Ciaran McCreesh wrote: >>> Note *the way things are currently*. If you think this is untrue, >>> provide an algorithm that will correctly give the EAPI of any >>> current or future ebuild given that

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-22 Thread Ciaran McCreesh
On Sat, 22 Dec 2007 16:55:50 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > Note *the way things are currently*. If you think this is untrue, > > provide an algorithm that will correctly give the EAPI of any > > current or future ebuild given that ebuild's filename (hint: yo

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-22 Thread Zhang Le
Ciaran McCreesh wrote: > On Sat, 22 Dec 2007 00:59:53 + > Steve Long <[EMAIL PROTECTED]> wrote: >>> It's so that the ebuild's EAPI can be extracted. The way things are >>> currently, there is no way to get an ebuild's EAPI without already >>> knowing its EAPI. >>> >> Like I said, it's trivial t

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-21 Thread Ciaran McCreesh
On Sat, 22 Dec 2007 00:59:53 + Steve Long <[EMAIL PROTECTED]> wrote: > >> Wow that doesn't half sound like nonsense. > > > > Unfortunately, it's not nonsense. It's entirely true. If you don't > > understand that then you can't contribute anything useful to the > > discussion, so kindly stay ou

[gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-21 Thread Steve Long
Ciaran McCreesh wrote: > On Thu, 20 Dec 2007 12:48:31 + > Steve Long <[EMAIL PROTECTED]> wrote: >> >> No: without knowing the EAPI when generating said data. If that >> >> needs to be known relatively soon in order to generate the rest, >> >> extract it early. You still only need to load the fi