Ciaran McCreesh <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on Wed, 19 Dec
2007 00:06:53 +:
>> And if a particular ebuild uses features from a non-conflicting
>> super-set of several such EAPIs (Ulrich's message) ...
>
> Then there should be an EAPI defined that permits al
Fernando J. Pereda wrote:
>> > Why can't it be in the file but readable without sourcing?
>> >
>> There's _no_ need to source, nor constrain like that, for a simple
>> one-line variable, eg:
>> $ sed -nr '/^[[:space:]]*DESCRIPTION="([^"]*)".*/ { s//\1/p;q; }' \
>> app-portage/autounmask/autoun
On Wed, 19 Dec 2007 08:12:24 +0100
Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:
> You're done as long as ebuilds are written in bash.
Not even that. What if people decide that rather than writing
EAPI="blah", "eapi blah" is cleaner? What if metadata is moved out of
the ebuild, as some pe
On Wed, 19 Dec 2007 10:26:16 +
Steve Long <[EMAIL PROTECTED]> wrote:
> Are you really telling me you are going to write _one_ ebuild
> with /that/ god-awful hackery in it?
Are you really suggesting that no-one ever will?
> Sticking to a single EAPI="xx" format in the ebuild means we don't
> h
Ciaran McCreesh wrote:
> On Wed, 19 Dec 2007 10:26:16 +
> Steve Long <[EMAIL PROTECTED]> wrote:
>> Are you really telling me you are going to write _one_ ebuild
>> with /that/ god-awful hackery in it?
>
> Are you really suggesting that no-one ever will?
>
They won't if the spec and the docs s
On Wed, 19 Dec 2007 00:07:22 +
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> On Tue, 18 Dec 2007 16:45:01 +0100
> Marius Mauch <[EMAIL PROTECTED]> wrote:
> > There is one significant problem not covered in the GLEP: If a
> > package contains an ebuild with a suffixed extension then all
> > deve
Ciaran McCreesh wrote:
> On Tue, 18 Dec 2007 21:38:08 +0100
> Fabian Groffen <[EMAIL PROTECTED]> wrote:
>> Just to have it spelt out, what you suggest here is that EAPI has a
>> single value, a word or a number, that refers to a set of "features
>> and rules", if I understand correctly.
>>
>> With
On Wednesday 19 of December 2007 15:27:07 Luca Barbato wrote:
> Fernando J. Pereda wrote:
> > On Tue, Dec 18, 2007 at 07:45:44PM +, Duncan wrote:
> >> 'app-shells/bash-3.2_p17-r1.ebuild-prefix 1 2 foo zork bar baz fa querty
> >> 3 8 4' (and that example uses no odd chars beyond the EAPI compone
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
>
>
How would it be different than having EAPI="string" put in a defined
position of the file?
lu
--
Luca Barbato
G
Fernando J. Pereda wrote:
> On Tue, Dec 18, 2007 at 07:45:44PM +, Duncan wrote:
>> "Fernando J. Pereda" <[EMAIL PROTECTED]> posted
>> [EMAIL PROTECTED], excerpted below, on Tue, 18 Dec 2007
>> 18:56:32 +0100:
>>
And as we have now learned that EAPI strings are not limited to digits
(
Piotr Jaroszyński wrote:
> Mixing EAPIs can't work.
Why? I'm afraid that before proposing that we could go back thinking
about which is the usage of EAPI.
Is the a concise and clear text about it already?
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~
On Wednesday 19 of December 2007 15:37:44 Luca Barbato wrote:
> How would it be different than having EAPI="string" put in a defined
> position of the file?
We wouldn't be able to take advantage of this GLEP for a year or so. But even
putting that aside I still prefer the filename approach for it
Piotr Jaroszyński wrote:
> On Wednesday 19 of December 2007 15:37:44 Luca Barbato wrote:
>> How would it be different than having EAPI="string" put in a defined
>> position of the file?
>
> We wouldn't be able to take advantage of this GLEP for a year or so.
I don't see why, articulate.
> But ev
On Wed, Dec 19, 2007 at 04:17:21PM +0100, Luca Barbato wrote:
> Piotr Jaroszyński wrote:
> > Mixing EAPIs can't work.
>
> Why?
Because EAPIs can define colliding features.
- ferdy
--
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
pgp90C5dzn9AZ.pgp
Descripti
"Fernando J. Pereda" <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 19, 2007 at 04:17:21PM +0100, Luca Barbato wrote:
> > Piotr Jaroszyński wrote:
> > > Mixing EAPIs can't work.
> >
> > Why?
>
> Because EAPIs can define colliding features.
The sense I've gotten from this discussion so far is that if y
Luca Barbato <[EMAIL PROTECTED]> wrote:
> How would it be different than having EAPI="string" put in a defined
> position of the file?
It's not - It is just defining that position to be in the name of the
file instead of the contents :)
--
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)
signat
On Wed, Dec 19, 2007 at 11:03:54AM -0500, Jim Ramsay wrote:
> "Fernando J. Pereda" <[EMAIL PROTECTED]> wrote:
> > On Wed, Dec 19, 2007 at 04:17:21PM +0100, Luca Barbato wrote:
> > > Piotr Jaroszyński wrote:
> > > > Mixing EAPIs can't work.
> > >
> > > Why?
> >
> > Because EAPIs can define collidi
Steve Long wrote:
> Ciaran McCreesh wrote:
>> There is no duplication of information, nor redundancy.
>>
> So what were the QA checks you mentioned to confirm that the same EAPI is
> set in both the filename and the ebuild, for-- if not integrity of
> duplicated data?
+1
>> Really. It's a heck of
On Wed, 19 Dec 2007 11:05:35 +
Steve Long <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 19 Dec 2007 10:26:16 +
> > Steve Long <[EMAIL PROTECTED]> wrote:
> >> Are you really telling me you are going to write _one_ ebuild
> >> with /that/ god-awful hackery in it?
> >
> > Ar
On Wed, 19 Dec 2007 15:18:28 +0100
Luca Barbato <[EMAIL PROTECTED]> wrote:
> > It doesn't *have* to be a perfect succession. It's entirely possible
> > that there will be, say, two divergent EAPI branches or even that
> > there will be a completely unrelated new EAPI format.
>
>
> What's the poin
> Steve Long wrote:
>> Ciaran McCreesh wrote:
>>> Really. It's a heck of a lot cleaner in the filename suffix.
>>>
>> Nah, it's an awful hack and you know it. It has nothing to do with package
>> naming and is unnecessary exposure of internal data.
>
Forgive me if I missed this in the previous 50
On Wed, 19 Dec 2007 18:59:47 -0500
Richard Freeman <[EMAIL PROTECTED]> wrote:
> Am I missing something?
Yes. You're missing all the explanations that have already been given
about why it's impossible to parse ebuilds using anything other than
bash.
--
Ciaran McCreesh
signature.asc
Description:
Ciaran McCreesh wrote:
>> >> Are you really telling me you are going to write _one_ ebuild
>> >> with /that/ god-awful hackery in it?
>> >
>> > Are you really suggesting that no-one ever will?
>> >
>> They won't if the spec and the docs say it's restricted to a single
>> instance, which can be che
On 23:20 Mon 17 Dec , Piotr Jaroszyński wrote:
> Abstract
>
>
> This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for
> example, foo-1.2.3.ebuild-1).
>
> Motivation
> ==
>
> Including EAPI in the ebuild file extension has the following advantages:
>
>
Ciaran McCreesh wrote:
> On Wed, 19 Dec 2007 18:59:47 -0500
> Richard Freeman <[EMAIL PROTECTED]> wrote:
>> Am I missing something?
>
> Yes. You're missing all the explanations that have already been given
> about why it's impossible to parse ebuilds using anything other than
> bash.
>
If the EA
Donnie Berkholz wrote:
> On 23:20 Mon 17 Dec , Piotr Jaroszyński wrote:
>> Abstract
>>
>>
>> This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for
>> example, foo-1.2.3.ebuild-1).
>>
>> Motivation
>> ==
>>
>> Including EAPI in the ebuild file extension has
On Thu, 20 Dec 2007 00:07:35 +
Steve Long <[EMAIL PROTECTED]> wrote:
> > Except people *do* have generated DESCRIPTION etc, and with good
> > reason. A simple example is the vim-spell-* packages.
> >
> OK. Do you think a generated EAPI is a good idea? I'm curious as to
> how that would be refle
On Wed, 19 Dec 2007 20:28:55 -0500
Richard Freeman <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 19 Dec 2007 18:59:47 -0500
> > Richard Freeman <[EMAIL PROTECTED]> wrote:
> >> Am I missing something?
> >
> > Yes. You're missing all the explanations that have already been
> > give
On 03:31 Thu 20 Dec , Luca Barbato wrote:
> Before spending even more time on it, could we try to come up with a
> definition of what eapi is, which problem is trying to solve and put
> that somewhere that isn't a long thread or an handful of threads
> scattered across mailing lists.
>
> Then
On Thu, 20 Dec 2007 03:31:14 +0100
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Before spending even more time on it, could we try to come up with a
> definition of what eapi is, which problem is trying to solve and put
> that somewhere that isn't a long thread or an handful of threads
> scattered acr
On 2007/12/19, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> On Wed, 19 Dec 2007 08:12:24 +0100
> Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:
> > You're done as long as ebuilds are written in bash.
>
> Not even that. What if people decide that rather than writing
> EAPI="blah", "eapi bl
On Thu, 20 Dec 2007 06:46:44 +0100
Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:
> On 2007/12/19, Ciaran McCreesh <[EMAIL PROTECTED]>
> wrote:
> > On Wed, 19 Dec 2007 08:12:24 +0100
> > Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:
> > > You're done as long as ebuilds are written
On 15:05 Mon 17 Dec , Jim Ramsay (lack) wrote:
> lack07/12/17 15:05:57
>
> Modified: ChangeLog
> Added:rox-2.7-r2.ebuild
> Log:
> Started using EAPI=1 and IUSE defaults. Also added new 'video' flag to
> IUSE (bug 202333)
> (Portage version: 2.1.3
Donnie Berkholz wrote:
> On 03:31 Thu 20 Dec , Luca Barbato wrote:
>> Before spending even more time on it, could we try to come up with a
>> definition of what eapi is, which problem is trying to solve and put
>> that somewhere that isn't a long thread or an handful of threads
>> scattered acr
Ciaran McCreesh wrote:
> On Thu, 20 Dec 2007 03:31:14 +0100
> Luca Barbato <[EMAIL PROTECTED]> wrote:
>> Before spending even more time on it, could we try to come up with a
>> definition of what eapi is, which problem is trying to solve and put
>> that somewhere that isn't a long thread or an hand
35 matches
Mail list logo
