Ciaran McCreesh wrote:
> On Sat, 22 Dec 2007 16:49:10 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>> Ciaran McCreesh wrote:
As long as there is an agreement in any given point of time, it is
OK. Such as, put your EAPI definition on the first line of your
ebuild, like EAPI="value"
>>>
Ciaran McCreesh wrote:
> On Sat, 22 Dec 2007 16:49:10 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>> Ciaran McCreesh wrote:
As long as there is an agreement in any given point of time, it is
OK. Such as, put your EAPI definition on the first line of your
ebuild, like EAPI="value"
>>>
On Sat, 22 Dec 2007 16:49:10 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> >> As long as there is an agreement in any given point of time, it is
> >> OK. Such as, put your EAPI definition on the first line of your
> >> ebuild, like EAPI="value"
> >
> > No good for package ma
Ciaran McCreesh wrote:
>> As long as there is an agreement in any given point of time, it is OK.
>> Such as, put your EAPI definition on the first line of your ebuild,
>> like EAPI="value"
>
> No good for package managers written before the agreement.
Why not force user to upgrade their PM?
After
On Fri, 21 Dec 2007 08:29:34 -0500
Richard Freeman <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Ok. What's the EAPI for the following ebuild that's written in an
> > EAPI that hasn't been published yet? And how would I extract it?
> >
> > # Copyright blah blah
> >
> > import vim-spell
Ciaran McCreesh wrote:
>
> Ok. What's the EAPI for the following ebuild that's written in an EAPI
> that hasn't been published yet? And how would I extract it?
>
> # Copyright blah blah
>
> import vim-spell using language="en"
>
Counterexample. How do you determine the eapi for the following
On Fri, 21 Dec 2007 12:20:31 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> It is not about whether it is agreed upon currently.
It is. That's the entire point of the whole discussion.
> As long as there is an agreement in any given point of time, it is OK.
> Such as, put your EAPI definition on the
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 11:51:03 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>> That's the problem about the agreement between PM and ebuild.
>>
>> If this is agreed upon
>>> import vim-spell using language="en"
>> You should be able to get it.
>>
>> If not, then blame the
On Fri, 21 Dec 2007 11:51:03 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> That's the problem about the agreement between PM and ebuild.
>
> If this is agreed upon
> > import vim-spell using language="en"
> You should be able to get it.
>
> If not, then blame the ebuild writer. There is no prob
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 10:52:04 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>> Ciaran McCreesh wrote:
>>> On Fri, 21 Dec 2007 03:14:12 +0100
>>> Luca Barbato <[EMAIL PROTECTED]> wrote:
Ciaran McCreesh wrote:
> Ok. What's the EAPI for the following ebuild that's writte
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 10:49:04 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>
>> It should not appear as a black box, and effectively prevent normal
>> gentoo users and developers from contributing to decisions which may
>> have a great impact on their distro.
>
> The GLEP d
On Fri, 21 Dec 2007 10:49:04 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> > Because the process is decidedly non-trivial, and anyone who hasn't
> > spent a considerable time studying it and understanding it isn't
> > going to be able to contribute anything useful anyway.
>
> But human beings are ab
On Fri, 21 Dec 2007 03:44:20 +0100
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Fri, 21 Dec 2007 03:14:12 +0100
> > Luca Barbato <[EMAIL PROTECTED]> wrote:
> >> Ciaran McCreesh wrote:
> >>> Ok. What's the EAPI for the following ebuild that's written in an
> >>> EAPI that
On Fri, 21 Dec 2007 10:52:04 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Fri, 21 Dec 2007 03:14:12 +0100
> > Luca Barbato <[EMAIL PROTECTED]> wrote:
> >> Ciaran McCreesh wrote:
> >>> Ok. What's the EAPI for the following ebuild that's written in an
> >>> EAPI that hasn
On Fri, 21 Dec 2007 03:14:12 +0100
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Ok. What's the EAPI for the following ebuild that's written in an
> > EAPI that hasn't been published yet? And how would I extract it?
> >
> > # Copyright blah blah
> >
> > import vim-spell usi
Ciaran McCreesh wrote:
> Ok. What's the EAPI for the following ebuild that's written in an EAPI
> that hasn't been published yet? And how would I extract it?
>
> # Copyright blah blah
>
> import vim-spell using language="en"
If isn't published it doesn't exist in the main tree...
lu
--
Luca
On Thu, 20 Dec 2007 08:56:01 -0500
Richard Freeman <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Because a) a future EAPI might want to change EAPI into a function
> > rather than a variable,
>
> Why? It couldn't be dynamic - not if you're going to put it in the
> filename as well. An
On Fri, 21 Dec 2007 02:45:48 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > And again, you show that you don't understand what's going on. EAPI
> > is only specified once except where developers screw up. The GLEP
> > merely moves the EAPI to being set *before* the metadata
On Fri, 21 Dec 2007 02:27:27 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > You need to understand the metadata generation process to
> > understand why the package manger has to assume a particular EAPI
> > when generating the metadata.
>
> There are many people watching
Ciaran McCreesh wrote:
> And again, you show that you don't understand what's going on. EAPI is
> only specified once except where developers screw up. The GLEP merely
> moves the EAPI to being set *before* the metadata is generated, which
> removes all the restrictions that having EAPI as part of
Ciaran McCreesh wrote:
>
> You need to understand the metadata generation process to understand why
> the package manger has to assume a particular EAPI when generating the
> metadata.
There are many people watching this thread all over the world I think.
Not all of them understand the process.
Ciaran McCreesh wrote:
> Because a) a future EAPI might want to change EAPI into a function
> rather than a variable,
Why? It couldn't be dynamic - not if you're going to put it in the
filename as well. And why have it in two places? If you are going to
put the EAPI in the filename, why put it
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
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
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:
> 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 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
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
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
29 matches
Mail list logo