[gentoo-dev] EAPI-2 - Let's get it started

[gentoo-dev] EAPI-2 - Let's get it started

[Doug Goldstein]

Let's try to aim to do an EAPI=2 sometime soonish since Portage now has 
USE flag depends in version 2.2 which is looming on the horizon. It'd be 
nice to hit the ground running with supporting these. I know it'll be 
trivial for the Paludis and pkgcore guys to make this work since they 
already support USE flag depends.

So... let's get the party started.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Patrick Lauer]

Doug Goldstein wrote:
> Let's try to aim to do an EAPI=2 sometime soonish since Portage now 
> has USE flag depends in version 2.2 which is looming on the horizon. 
> It'd be nice to hit the ground running with supporting these. I know 
> it'll be trivial for the Paludis and pkgcore guys to make this work 
> since they already support USE flag depends.
>
> So... let's get the party started.
The question is then, what features do people want there?

I've seen a few things mentioned, but I presume there are two 
restrictions -
1) feature needs to be reasonably useful to enough people
2) feature needs to be implementable in a short enough timeframe

So EAPI 2 is not "everything shiny", but a small iterative improvement 
to EAPI 1.

Suggest features then and let's discuss!
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Nirbheek Chauhan]

On Tue, Jun 10, 2008 at 10:00 PM, Patrick Lauer
<bugs@dev.gentooexperimental.org> wrote:
> So EAPI 2 is not "everything shiny", but a small iterative improvement to
> EAPI 1.
>
> Suggest features then and let's discuss!

For reference of existing ideas -- https://bugs.gentoo.org/174380 -- a
tracker for EAPI feature requests.

I personally like https://bugs.gentoo.org/197859 the most -- split out
src_configure from src_compile which will allow sane resuming of
compiles :)

-- 
~Nirbheek Chauhan
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Doug Goldstein]

Nirbheek Chauhan wrote:
> On Tue, Jun 10, 2008 at 10:00 PM, Patrick Lauer
> <bugs@dev.gentooexperimental.org> wrote:
>   
>> So EAPI 2 is not "everything shiny", but a small iterative improvement to
>> EAPI 1.
>>
>> Suggest features then and let's discuss!
>>     
>
> For reference of existing ideas -- https://bugs.gentoo.org/174380 -- a
> tracker for EAPI feature requests.
>
> I personally like https://bugs.gentoo.org/197859 the most -- split out
> src_configure from src_compile which will allow sane resuming of
> compiles :)
>
>   
At this point, we should really only discuss features that all 3 package 
managers have implemented.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Richard Brown]

On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <cardoe@gentoo.org> wrote:
> At this point, we should really only discuss features that all 3 package
> managers have implemented.

I'm not sure that's a good idea, only two have implemented EAPI 1 so far.

-- 
Richard Brown
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Patrick Lauer]

On Tuesday 10 June 2008 16:54:49 Richard Brown wrote:
> On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <cardoe@gentoo.org> wrote:
> > At this point, we should really only discuss features that all 3 package
> > managers have implemented.
>
> I'm not sure that's a good idea, only two have implemented EAPI 1 so far.
>
Yes, but noone cares about Paludis.

Now could you please do the rest of us a favour and keep the discussion 
focussed on improving technical details instead of random insults at others?

Thanks ...
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Fernando J. Pereda]

On 10 Jun 2008, at 19:06, Patrick Lauer wrote:

> On Tuesday 10 June 2008 16:54:49 Richard Brown wrote:
>> On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <cardoe@gentoo.org>  
>> wrote:
>>> At this point, we should really only discuss features that all 3  
>>> package
>>> managers have implemented.
>>
>> I'm not sure that's a good idea, only two have implemented EAPI 1  
>> so far.
>>
> Yes, but noone cares about Paludis.

Ah, Paludis does support EAPI-1 just fine. Thank you.

- ferdy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Alistair Bush]

Patrick Lauer wrote:
> On Tuesday 10 June 2008 16:54:49 Richard Brown wrote:
>> On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <cardoe@gentoo.org> wrote:
>>> At this point, we should really only discuss features that all 3 package
>>> managers have implemented.
>> I'm not sure that's a good idea, only two have implemented EAPI 1 so far.
>>
> Yes, but noone cares about Paludis.
> 
> Now could you please do the rest of us a favour and keep the discussion 
> focussed on improving technical details instead of random insults at others?

Isn't that, in itself, an insult and you don't seem to have advanced the 
discussion at all.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

On Tue, Jun 10, 2008 at 05:54:49PM +0100, Richard Brown wrote:
> On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <cardoe@gentoo.org> wrote:
> > At this point, we should really only discuss features that all 3 package
> > managers have implemented.
> 
> I'm not sure that's a good idea, only two have implemented EAPI 1 so far.

3 have.  If you're aware of a pkgcore issue, then kindly file a bug 
rather then going for mocking on -dev.

Cheers.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

On Tue, 10 Jun 2008 17:11:23 -0700
Brian Harring <ferringb@gmail.com> wrote:
> On Tue, Jun 10, 2008 at 05:54:49PM +0100, Richard Brown wrote:
> > On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <cardoe@gentoo.org>
> > wrote:
> > > At this point, we should really only discuss features that all 3
> > > package managers have implemented.
> > 
> > I'm not sure that's a good idea, only two have implemented EAPI 1
> > so far.
> 
> 3 have.  If you're aware of a pkgcore issue, then kindly file a bug 
> rather then going for mocking on -dev.

Had you bothered to write even trivial test suites for EAPI 1, you'd've
found at least one major bug straight away. Do everyone a favour and
write yourself a load of unit tests for every bit of changed
functionality in EAPI 1. 

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Ciaran McCreesh wrote:
> On Tue, 10 Jun 2008 17:11:23 -0700
> Brian Harring <ferringb@gmail.com> wrote:
>> On Tue, Jun 10, 2008 at 05:54:49PM +0100, Richard Brown wrote:
>>> On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <cardoe@gentoo.org>
>>> wrote:
>>>> At this point, we should really only discuss features that all 3
>>>> package managers have implemented.
>>> I'm not sure that's a good idea, only two have implemented EAPI 1
>>> so far.
>> 3 have.  If you're aware of a pkgcore issue, then kindly file a bug 
>> rather then going for mocking on -dev.
> 
> Had you bothered to write even trivial test suites for EAPI 1, you'd've
> found at least one major bug straight away.

http://www.pkgcore.org/trac/pkgcore/newticket

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

On Wed, 11 Jun 2008 08:02:48 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> > Had you bothered to write even trivial test suites for EAPI 1,
> > you'd've found at least one major bug straight away.
> 
> http://www.pkgcore.org/trac/pkgcore/newticket

http://www.pkgcore.org/trac/pkgcore/ticket/197

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Richard Freeman]

Ciaran McCreesh wrote:
> On Wed, 11 Jun 2008 08:02:48 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>>> Had you bothered to write even trivial test suites for EAPI 1,
>>> you'd've found at least one major bug straight away.
>> http://www.pkgcore.org/trac/pkgcore/newticket
> 
> http://www.pkgcore.org/trac/pkgcore/ticket/197
> 

Uh - what is the goal on this list - to make Gentoo a better 
distribution or to point out that the package manager that I maintain is 
better than the package manager that you maintain?

Gentoo is served by having lots of package managers that all work well. 
  If somebody knows of a bug and intentionally doesn't report it, 
they're being rather selfish.  That's like posting "ha, ha - I found a 
zero-day exploit in apache and if you were as elite as me you'd have 
found it in your testing!"

There is an old adage - if you're not part of the solution you're part 
of the problem.

And if you don't want to be part of the solution, then why are you 
wasting your time here?  I'm a big fan of PMS/paludis/etc in general, 
but why waste your time contributing these things to Gentoo if you don't 
want Gentoo to succeed?  If you do want Gentoo to succeed, then why not 
give others a helping hand when it costs you virtually nothing to do so?
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]

On Wed, 11 Jun 2008 06:55:45 -0400
Richard Freeman <rich0@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 11 Jun 2008 08:02:48 +0200
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >>> Had you bothered to write even trivial test suites for EAPI 1,
> >>> you'd've found at least one major bug straight away.
> >> http://www.pkgcore.org/trac/pkgcore/newticket
> > 
> > http://www.pkgcore.org/trac/pkgcore/ticket/197
> 
> Uh - what is the goal on this list - to make Gentoo a better 
> distribution or to point out that the package manager that I maintain
> is better than the package manager that you maintain?

The point is to make pkgcore a better package manager by getting the
developers to do some basic testing. We're not talking some obscure,
weird bug here. We're talking a really obvious, major screwup that a
couple of quick unit tests would catch straight away.

> And if you don't want to be part of the solution, then why are you 
> wasting your time here?  I'm a big fan of PMS/paludis/etc in general, 
> but why waste your time contributing these things to Gentoo if you
> don't want Gentoo to succeed?  If you do want Gentoo to succeed, then
> why not give others a helping hand when it costs you virtually
> nothing to do so?

Give a man a bug report and he fixes one bug. Persuade a man to write
basic unit tests and he fixes a whole load of bugs and catches a whole
load more in the future before shipping them out. And then you give him
bug reports for what that doesn't catch.

The problem is, the pkgcore people are being blatantly irresponsible by
sticking a package manager that claims to support EAPI 1 in the tree
without actually supporting EAPI 1. In particular, it means we'll have
to decide whether to avoid using some EAPI 1 features just to avoid
breaking people using older pkgcore versions.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Ciaran McCreesh wrote:
> The point is to make pkgcore a better package manager by getting the
> developers to do some basic testing. We're not talking some obscure,
> weird bug here. We're talking a really obvious, major screwup that a
> couple of quick unit tests would catch straight away.

No, you aren't talking, you are babbling about undefined flaws that 
nobody can evaluate, for which you aren't providing a way to reproduce 
it and possibly doesn't exist.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Bernd Steinhauser]

Luca Barbato schrieb:
> Ciaran McCreesh wrote:
>> The point is to make pkgcore a better package manager by getting the
>> developers to do some basic testing. We're not talking some obscure,
>> weird bug here. We're talking a really obvious, major screwup that a
>> couple of quick unit tests would catch straight away.
> 
> No, you aren't talking, you are babbling about undefined flaws that 
> nobody can evaluate, for which you aren't providing a way to reproduce 
> it and possibly doesn't exist.
> 
> lu
> 
So in your opinion, the pkgcore maintainers should just say "Screw it, 
it was just Ciaran who said that." and move on?

Why is "Create tests for EAPI=1 stuff." not a way to describe how to 
reproduce a problem?

Talking away problems, now that is a way to handle QA.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Patrick Lauer]

Bernd Steinhauser wrote:
> Luca Barbato schrieb:
>> Ciaran McCreesh wrote:
>>> The point is to make pkgcore a better package manager by getting the
>>> developers to do some basic testing. We're not talking some obscure,
>>> weird bug here. We're talking a really obvious, major screwup that a
>>> couple of quick unit tests would catch straight away.
>>
>> No, you aren't talking, you are babbling about undefined flaws that 
>> nobody can evaluate, for which you aren't providing a way to 
>> reproduce it and possibly doesn't exist.
>>
>> lu
>>
> So in your opinion, the pkgcore maintainers should just say "Screw it, 
> it was just Ciaran who said that." and move on?
No, it's just unsubstantiated rumors. As such they are irrelevant until 
some kind of proof is shown.
>
> Why is "Create tests for EAPI=1 stuff." not a way to describe how to 
> reproduce a problem?
It is too generic and doesn't even describe the class of bug. By the 
same rationale portage and paludis have multiple bugs ...
>
> Talking away problems, now that is a way to handle QA.
So, could anyone just actually mention what the problem is, or is the 
hivemind not able to express such a simple thing?

Just think of the thousands of emails, being read by hundreds of 
readers, that have cost so much time ... in that time you could have 
written a patch and a bugreport.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Bernd Steinhauser]

Patrick Lauer schrieb:
> Bernd Steinhauser wrote:
>> Luca Barbato schrieb:
>>> Ciaran McCreesh wrote:
>>>> The point is to make pkgcore a better package manager by getting the
>>>> developers to do some basic testing. We're not talking some obscure,
>>>> weird bug here. We're talking a really obvious, major screwup that a
>>>> couple of quick unit tests would catch straight away.
>>>
>>> No, you aren't talking, you are babbling about undefined flaws that 
>>> nobody can evaluate, for which you aren't providing a way to 
>>> reproduce it and possibly doesn't exist.
>>>
>>> lu
>>>
>> So in your opinion, the pkgcore maintainers should just say "Screw it, 
>> it was just Ciaran who said that." and move on?
> No, it's just unsubstantiated rumors. As such they are irrelevant until 
> some kind of proof is shown.
It might be, but it might also be a bug.
Of course the maintainers can choose if they go after it.

BTW: The Paludis maintainers did have a look at the "security hole" you 
pointed out, even though everyone knows, that you spread lies about 
Paludis...

>> Why is "Create tests for EAPI=1 stuff." not a way to describe how to 
>> reproduce a problem?
> It is too generic and doesn't even describe the class of bug. By the 
> same rationale portage and paludis have multiple bugs ...
It is indeed generic, but then you should test every part of EAPI.
The main point was, that test are missing and the fact, that there is 
might be a bug, that they didn't catch yet is a follow up.

Of course, filing a bug report for a single issue might get that issue 
fixed, but what caused this issue to be still there (missing tests) will 
still be there.

>> Talking away problems, now that is a way to handle QA.
> So, could anyone just actually mention what the problem is, or is the 
> hivemind not able to express such a simple thing?
> 
> Just think of the thousands of emails, being read by hundreds of 
> readers, that have cost so much time ... in that time you could have 
> written a patch and a bugreport.
Again, one patch and one bug report wouldn't wipe out the problem in the 
long term view.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Bernd Steinhauser wrote:
> Luca Barbato schrieb:
>> Ciaran McCreesh wrote:
>>> The point is to make pkgcore a better package manager by getting the
>>> developers to do some basic testing. We're not talking some obscure,
>>> weird bug here. We're talking a really obvious, major screwup that a
>>> couple of quick unit tests would catch straight away.
>>
>> No, you aren't talking, you are babbling about undefined flaws that 
>> nobody can evaluate, for which you aren't providing a way to reproduce 
>> it and possibly doesn't exist.
>>
>> lu
>>
> So in your opinion, the pkgcore maintainers should just say "Screw it, 
> it was just Ciaran who said that." and move on?

He doesn't point any issue in particular.

> Why is "Create tests for EAPI=1 stuff." not a way to describe how to 
> reproduce a problem?

because EAPI1 isn't specified completely so you don't have a large field 
to cover but you also do not know the bounds of it.

Assuming that Ciaranm isn't just lying knowingly it's just plainly rude, 
otherwise it is pure malice.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

On Wed, 11 Jun 2008 14:49:19 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> > Why is "Create tests for EAPI=1 stuff." not a way to describe how
> > to reproduce a problem?
> 
> because EAPI1 isn't specified completely so you don't have a large
> field to cover but you also do not know the bounds of it.

EAPI 1 is entirely specified in terms of a diff against EAPI 0.
Checking every part that's changed before releasing an EAPI 1 package
manager is the least any responsible person would do. That they would
release a version without doing such basic tests shows you just how
much they care about Gentoo...

> Assuming that Ciaranm isn't just lying knowingly it's just plainly
> rude, otherwise it is pure malice.

What, asking the pkgcore people to test their code before releasing a
version that claims to support EAPI 1 but actually doesn't, forcing
people to avoid using some of EAPI 1 to avoid breaking pkgcore, is
malice?

The whole "EAPI lets us do upgrades cleanly" process is broken when
people release a package manager that claims to support a certain EAPI
but doesn't. If pkgcore had any actual users we'd have to consider
banning EAPI 1 in the tree and releasing EAPI 2 as being identical to
EAPI 1 just to work around this.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Ciaran McCreesh wrote:
> EAPI 1 is entirely specified in terms of a diff against EAPI 0.

That doesn't have a complete definition by itself.

> Checking every part that's changed before releasing an EAPI 1 package
> manager is the least any responsible person would do. That they would
> release a version without doing such basic tests shows you just how
> much they care about Gentoo...

Again smearing without substance.

>> Assuming that Ciaranm isn't just lying knowingly it's just plainly
>> rude, otherwise it is pure malice.
> 
> What, asking the pkgcore people to test their code before releasing a
> version that claims to support EAPI 1 but actually doesn't, forcing
> people to avoid using some of EAPI 1 to avoid breaking pkgcore, is
> malice?

Saying that w/out giving any substance? Sure!

> The whole "EAPI lets us do upgrades cleanly" process is broken when
> people release a package manager that claims to support a certain EAPI
> but doesn't. If pkgcore had any actual users we'd have to consider
> banning EAPI 1 in the tree and releasing EAPI 2 as being identical to
> EAPI 1 just to work around this.

Apparently those users do not see the problem, you do, help those blind 
people.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

On Wed, 11 Jun 2008 15:05:47 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > EAPI 1 is entirely specified in terms of a diff against EAPI 0.
> 
> That doesn't have a complete definition by itself.

It's more than enough to write unit tests to ensure that all things
changed from 0 to 1 are functioning correctly.

> > Checking every part that's changed before releasing an EAPI 1
> > package manager is the least any responsible person would do. That
> > they would release a version without doing such basic tests shows
> > you just how much they care about Gentoo...
> 
> Again smearing without substance.

So you're saying they did do adequate testing before releasing, and
that you're happy to have the use of EAPIs in Gentoo's tree being
restricted by pkgcore's level of testing?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]

On Wed, Jun 11, 2008 at 02:00:19PM +0100, Ciaran McCreesh wrote:
> On Wed, 11 Jun 2008 14:49:19 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
> > > Why is "Create tests for EAPI=1 stuff." not a way to describe how
> > > to reproduce a problem?
> > 
> > because EAPI1 isn't specified completely so you don't have a large
> > field to cover but you also do not know the bounds of it.
> 
> EAPI 1 is entirely specified in terms of a diff against EAPI 0.
> Checking every part that's changed before releasing an EAPI 1 package
> manager is the least any responsible person would do. That they would
> release a version without doing such basic tests shows you just how
> much they care about Gentoo...
> 
> > Assuming that Ciaranm isn't just lying knowingly it's just plainly
> > rude, otherwise it is pure malice.
> 
> What, asking the pkgcore people to test their code before releasing a
> version that claims to support EAPI 1 but actually doesn't, forcing
> people to avoid using some of EAPI 1 to avoid breaking pkgcore, is
> malice?
> 
> The whole "EAPI lets us do upgrades cleanly" process is broken when
> people release a package manager that claims to support a certain EAPI
> but doesn't. If pkgcore had any actual users we'd have to consider
> banning EAPI 1 in the tree and releasing EAPI 2 as being identical to
> EAPI 1 just to work around this.

Ya know ciaran, I've just got to point out that you spend quite a 
large amount of time talking about pkgcore.  Literaly- you talk about 
it more then I do.

I could point out how paludis (or portage) has picked up the misc 
functionality pkgcore (then known as saviour, or ebd) established 4 
years back, but hey, I'm not petty like you.  Generators aren't at all 
like the basic repository concept, no sir.  But you know that, of 
course, and of course you've got nothing to worry about from pkgcore, 
no sir.

Alternatively, I'll take your tack- eapi1 actually isn't supported by 
paludis.  Ask me what bug, please, trust me I'll make it entertaining 
for the gentoo-dev readers.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

On Wed, 11 Jun 2008 06:08:20 -0700
Brian Harring <ferringb@gmail.com> wrote:
> Ya know ciaran, I've just got to point out that you spend quite a 
> large amount of time talking about pkgcore.  Literaly- you talk about 
> it more then I do.

Unfortunately, since you don't care about implementing EAPIs
correctly, I have to worry about it. Kinda important to make sure that
PMS is universal, you know...

> Generators aren't at all like the basic repository concept, no sir.

Er, no, they aren't. They're an entirely different model. It's good to
see you're trying to learn how to be a better programmer by avidly
reading everything I write, but please pay more attention. Confusing
generators and repositories is about on par with confusing a spoon and
an apple pie.

> Alternatively, I'll take your tack- eapi1 actually isn't supported by 
> paludis.  Ask me what bug, please, trust me I'll make it entertaining 
> for the gentoo-dev readers.

Ah, but I have unit tests, so I can be confident when I say that we're
correctly implementing the EAPI 1 changes. Unlike you, I don't have
such a high degree of confidence in Paludis contributors' (including
myself) abilities to write perfect code the first time that I let
changes go through without testing to ensure that they work.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Bernd Steinhauser]

Luca Barbato schrieb:
> Bernd Steinhauser wrote:
>> Luca Barbato schrieb:
>>> Ciaran McCreesh wrote:
>>>> The point is to make pkgcore a better package manager by getting the
>>>> developers to do some basic testing. We're not talking some obscure,
>>>> weird bug here. We're talking a really obvious, major screwup that a
>>>> couple of quick unit tests would catch straight away.
>>>
>>> No, you aren't talking, you are babbling about undefined flaws that 
>>> nobody can evaluate, for which you aren't providing a way to 
>>> reproduce it and possibly doesn't exist.
>>>
>>> lu
>>>
>> So in your opinion, the pkgcore maintainers should just say "Screw it, 
>> it was just Ciaran who said that." and move on?
> 
> He doesn't point any issue in particular.
And that wasn't the point. He pointed out, that there is an issue, that 
hasn't been caught because of missing tests.

>> Why is "Create tests for EAPI=1 stuff." not a way to describe how to 
>> reproduce a problem?
> 
> because EAPI1 isn't specified completely so you don't have a large field 
> to cover but you also do not know the bounds of it.
It really doesn't matter how it is specified. You have an implementation 
of it and should make sure, that this implementation works.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Bernd Steinhauser wrote:
>> He doesn't point any issue in particular.
> And that wasn't the point. He pointed out, that there is an issue, that 
> hasn't been caught because of missing tests.

That may or may not exist

>> because EAPI1 isn't specified completely so you don't have a large 
>> field to cover but you also do not know the bounds of it.
> It really doesn't matter how it is specified. You have an implementation 
> of it and should make sure, that this implementation works.

Seems to works well enough for people using it.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

On Wed, 11 Jun 2008 15:20:55 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> >> because EAPI1 isn't specified completely so you don't have a large 
> >> field to cover but you also do not know the bounds of it.
> > It really doesn't matter how it is specified. You have an
> > implementation of it and should make sure, that this implementation
> > works.
> 
> Seems to works well enough for people using it.

Presumably those people, if they exist, haven't tried to go through and
install every EAPI 1 package in the tree (excluding KDE, since that's
big and slow, and starting backwards since the x11- categories are nice
and pretty).

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Patrick Lauer]

Ciaran McCreesh wrote:
> On Wed, 11 Jun 2008 15:20:55 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>   
>>>> because EAPI1 isn't specified completely so you don't have a large 
>>>> field to cover but you also do not know the bounds of it.
>>>>         
>>> It really doesn't matter how it is specified. You have an
>>> implementation of it and should make sure, that this implementation
>>> works.
>>>       
>> Seems to works well enough for people using it.
>>     
>
> Presumably those people, if they exist, haven't tried to go through and
> install every EAPI 1 package in the tree (excluding KDE, since that's
> big and slow, and starting backwards since the x11- categories are nice
> and pretty).
>
>   
I did. Can't reproduce. Go away.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

On Wed, 11 Jun 2008 15:34:43 +0200
Patrick Lauer <bugs@dev.gentooexperimental.org> wrote:
> > Presumably those people, if they exist, haven't tried to go through
> > and install every EAPI 1 package in the tree (excluding KDE, since
> > that's big and slow, and starting backwards since the x11-
> > categories are nice and pretty).
> >
> I did. Can't reproduce. Go away.

Then you should probably see a doctor. Also, you should really check
your results a lot more carefully -- perhaps there's also a bug in your
build tool that makes it not recognise when something fails?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Ciaran McCreesh wrote:
> Presumably those people, if they exist, haven't tried to go through and
> install every EAPI 1 package in the tree (excluding KDE, since that's
> big and slow, and starting backwards since the x11- categories are nice
> and pretty).

Nice game, still you aren't giving substance to your claims.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[David Leverton]

On Wednesday 11 June 2008 14:20:55 Luca Barbato wrote:
> Bernd Steinhauser wrote:
> > And that wasn't the point. He pointed out, that there is an issue, that
> > hasn't been caught because of missing tests.
>
> That may or may not exist

Since at least one ebuild has already been modified specifically to work 
around the bug, I'd say it's pretty real.

> > It really doesn't matter how it is specified. You have an implementation
> > of it and should make sure, that this implementation works.
>
> Seems to works well enough for people using it.

Unfortunately, that's not really saying much.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Jim Ramsay]

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

David Leverton <levertond@googlemail.com> wrote:
> Since at least one ebuild has already been modified specifically to
> work around the bug, I'd say it's pretty real.

For those of us trying to play along at home, which one is this?

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[David Leverton]

On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote:
> David Leverton <levertond@googlemail.com> wrote:
> > Since at least one ebuild has already been modified specifically to
> > work around the bug, I'd say it's pretty real.
>
> For those of us trying to play along at home, which one is this?

http://tinyurl.com/4w4t69
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Roy Marples]

On Wednesday 11 June 2008 19:00:16 David Leverton wrote:
> On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote:
> > David Leverton <levertond@googlemail.com> wrote:
> > > Since at least one ebuild has already been modified specifically to
> > > work around the bug, I'd say it's pretty real.
> >
> > For those of us trying to play along at home, which one is this?
>
> http://tinyurl.com/4w4t69

Why the need for EAPI=1?
A cursory glance shows nothing unusual.

Thanks

Roy
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Fabian Groffen]

On 11-06-2008 20:24:18 +0100, Roy Marples wrote:
> On Wednesday 11 June 2008 19:00:16 David Leverton wrote:
> > On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote:
> > > David Leverton <levertond@googlemail.com> wrote:
> > > > Since at least one ebuild has already been modified specifically to
> > > > work around the bug, I'd say it's pretty real.
> > >
> > > For those of us trying to play along at home, which one is this?
> >
> > http://tinyurl.com/4w4t69
> 
> Why the need for EAPI=1?
> A cursory glance shows nothing unusual.

slot deps


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] eapi1 bug/pkgcore sucks thread [was EAPI-2 - Let's get it started]

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2304 bytes --]

On Wed, Jun 11, 2008 at 07:00:16PM +0100, David Leverton wrote:
> On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote:
> > David Leverton <levertond@googlemail.com> wrote:
> > > Since at least one ebuild has already been modified specifically to
> > > work around the bug, I'd say it's pretty real.
> >
> > For those of us trying to play along at home, which one is this?
> 
> http://tinyurl.com/4w4t69

Few things I'll note about this stupid, stupid mess- looks of it, 
paludis folk have known about this for a while.  In other words, folk 
bitching about 'improving' QA intentionally sat on a bug for the sake 
of mocking, bug which according to them ebuild devs have supposedly 
worked around (yet to see it, but it's viable).

Useful to the whole, I'm sure.  Same folk in control of PMS for those 
playing the home game, politics over QA seemingly.

So what was the bug?  Aside from having to walk the full eapi-1 bugs,
(ebuild referenced wasn't of use), majority of which actually *is* 
tested in pkgcore (unlike portage which makes one wonder why pkgcore 
is targeted), the fault is a simple defaulting of an unset var being 
missed in implementing an undocumented spec (honestly, where is eapi1 
spec?).

Literally, the BS of the last day all comes down to inability to state 
the following:

=== modified file 'pkgcore/bin/ebuild-env/ebuild-functions.sh'
--- pkgcore/bin/ebuild-env/ebuild-functions.sh	2007-11-12 01:17:24 +0000
+++ pkgcore/bin/ebuild-env/ebuild-functions.sh	2008-06-11 22:24:16 +0000
@@ -236,7 +236,7 @@ src_compile
 {
     if [ "${EAPI:-0}" == 0 ] ; then
         [ -x ./configure ] && econf
-    elif [ -x ${ECONF_SOURCE}/configure ]; then
+    elif [ -x ${ECONF_SOURCE:-.}/configure ]; then
         econf || die "econf failed"
     fi
     if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then


Bit of a dumb bug, but it occurs unfortunately.  And yes, bash bits 
aren't currently tested since they're going to be completely ripped 
out and replaced (in the process shifting where/how it's accessed).

Why the exherbo/paludis/PMS folk decided to go this route to report, 
I'm not quite sure aside from assuming they're just griefers.

Regardless, fixed, released as 0.4.7.4, and in the tree.

Cheers
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] eapi1 bug/pkgcore sucks thread [was EAPI-2 - Let's get it started]

[Fernando J. Pereda]

On 12 Jun 2008, at 04:16, Brian Harring wrote:
>
> Why the exherbo/paludis/PMS folk decided to go this route to report,
> I'm not quite sure aside from assuming they're just griefers.

s-exherbo/paludis/PMS-pkgcore-g and:

http://fpereda.wordpress.com/2008/05/03/on-cooperating-and-paludis-vulnerability/

Except this one wasn't a lie.

I wish there were more cooperation between all of us. But looks like  
it is impossible with some of your people.

- ferdy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] eapi1 bug/pkgcore sucks thread [was EAPI-2 - Let's get it started]

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

On Thu, Jun 12, 2008 at 11:39:21AM +0200, Fernando J. Pereda wrote:
> 
> On 12 Jun 2008, at 04:16, Brian Harring wrote:
> >
> >Why the exherbo/paludis/PMS folk decided to go this route to report,
> >I'm not quite sure aside from assuming they're just griefers.
> 
> s-exherbo/paludis/PMS-pkgcore-g and:
> 
> http://fpereda.wordpress.com/2008/05/03/on-cooperating-and-paludis-vulnerability/
> 
> Except this one wasn't a lie.
> 
> I wish there were more cooperation between all of us. But looks like  
> it is impossible with some of your people.

While patrick hosts meatoo for pythonhead, that doesn't mean patrick 
can speak for meatoo.

The same applies for pkgcore.

Basically, I don't hold paludis devs responsible for their users 
behaviour (probably should considering the behaviour, but regardless).  
I do however hold paludis devs responsible for their *own* behaviour- 
and in this particular case, it *was* said devs commiting the 
offense.

Deflection aside, dropping the issue- I've made my point that it was 
serious crap behaviour and hardly in the spirit of cooperation (let 
alone QA).
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] eapi1 bug/pkgcore sucks thread [was EAPI-2 - Let's get it started]

[Steev Klimaszewski]

On Thu, 2008-06-12 at 11:39 +0200, Fernando J. Pereda wrote:
> On 12 Jun 2008, at 04:16, Brian Harring wrote:
> >
> > Why the exherbo/paludis/PMS folk decided to go this route to report,
> > I'm not quite sure aside from assuming they're just griefers.
> 
> s-exherbo/paludis/PMS-pkgcore-g and:
> 
> http://fpereda.wordpress.com/2008/05/03/on-cooperating-and-paludis-vulnerability/
> 
> Except this one wasn't a lie.
> 
> I wish there were more cooperation between all of us. But looks like  
> it is impossible with some of your people.
> 
> - ferdy
> 

Please stop whoring the url for that, its old already.  There is a huge
difference between that and knowingly witholding information because you
"want to see unit tests done."  Quit being a fuckwit.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] eapi1 bug/pkgcore sucks thread [was EAPI-2 - Let's get it started]

[Thomas Anderson]

[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]

On Wed, Jun 11, 2008 at 07:16:05PM -0700, Brian Harring wrote:
> On Wed, Jun 11, 2008 at 07:00:16PM +0100, David Leverton wrote:
> > On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote:
> > > David Leverton <levertond@googlemail.com> wrote:
> > > > Since at least one ebuild has already been modified specifically to
> > > > work around the bug, I'd say it's pretty real.
> > >
> > > For those of us trying to play along at home, which one is this?
> > 
> > http://tinyurl.com/4w4t69
> 
> Few things I'll note about this stupid, stupid mess- looks of it, 
> paludis folk have known about this for a while.  In other words, folk 
> bitching about 'improving' QA intentionally sat on a bug for the sake 
> of mocking, bug which according to them ebuild devs have supposedly 
> worked around (yet to see it, but it's viable).
> 
> Useful to the whole, I'm sure.  Same folk in control of PMS for those 
> playing the home game, politics over QA seemingly.
> 
> So what was the bug?  Aside from having to walk the full eapi-1 bugs,
> (ebuild referenced wasn't of use), majority of which actually *is* 
> tested in pkgcore (unlike portage which makes one wonder why pkgcore 
> is targeted), the fault is a simple defaulting of an unset var being 
> missed in implementing an undocumented spec (honestly, where is eapi1 
> spec?).
> 
> Literally, the BS of the last day all comes down to inability to state 
> the following:
> 
> === modified file 'pkgcore/bin/ebuild-env/ebuild-functions.sh'
> --- pkgcore/bin/ebuild-env/ebuild-functions.sh	2007-11-12 01:17:24 +0000
> +++ pkgcore/bin/ebuild-env/ebuild-functions.sh	2008-06-11 22:24:16 +0000
> @@ -236,7 +236,7 @@ src_compile
>  {
>      if [ "${EAPI:-0}" == 0 ] ; then
>          [ -x ./configure ] && econf
> -    elif [ -x ${ECONF_SOURCE}/configure ]; then
> +    elif [ -x ${ECONF_SOURCE:-.}/configure ]; then
>          econf || die "econf failed"
>      fi
>      if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
> 
>

I'm not quite sure how you're trying to present this, but are you really
trying to say that EAPI 1 isn't documented? I myself found this in
pms.pdf in 2 minutes(it's section 10.1.3). I wouldn't exactly say it's
because it was "missed in implementing an undocumented spec."

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] eapi1 bug/pkgcore sucks thread [was EAPI-2 - Let's get it started]

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

On Thu, Jun 12, 2008 at 07:02:52AM -0400, Thomas Anderson wrote:
> On Wed, Jun 11, 2008 at 07:16:05PM -0700, Brian Harring wrote:
> I'm not quite sure how you're trying to present this, but are you really
> trying to say that EAPI 1 isn't documented? I myself found this in
> pms.pdf in 2 minutes(it's section 10.1.3). I wouldn't exactly say it's
> because it was "missed in implementing an undocumented spec."

Stand corrected- last time I shot through checking into eapi1, the 
only spot I could find information in a singular place is bugs.g.o; w/ 
the kdebuild merge to pms, they at least built up a table of 
capabilities/per eapi.

One thing missing in the doc is the delta between 0 and 1, without 
scraping the whole doc to identify the diffs (such a thing would be 
useful).

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Fernando J. Pereda]

On 10 Jun 2008, at 18:39, Doug Goldstein wrote:

> Nirbheek Chauhan wrote:
>> On Tue, Jun 10, 2008 at 10:00 PM, Patrick Lauer
>> <bugs@dev.gentooexperimental.org> wrote:
>>
>>> So EAPI 2 is not "everything shiny", but a small iterative  
>>> improvement to
>>> EAPI 1.
>>>
>>> Suggest features then and let's discuss!
>>>
>>
>> For reference of existing ideas -- https://bugs.gentoo.org/174380  
>> -- a
>> tracker for EAPI feature requests.
>>
>> I personally like https://bugs.gentoo.org/197859 the most -- split  
>> out
>> src_configure from src_compile which will allow sane resuming of
>> compiles :)
>>
>>
> At this point, we should really only discuss features that all 3  
> package managers have implemented.

I'm not sure this intersection isn't empty :/

We might, however, only discuss features that all 3 package managers  
can implement easily.

- ferdy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Nirbheek Chauhan]

On Tue, Jun 10, 2008 at 11:04 PM, Fernando J. Pereda <ferdy@gentoo.org> wrote:
>
> On 10 Jun 2008, at 18:39, Doug Goldstein wrote:
>> At this point, we should really only discuss features that all 3 package
>> managers have implemented.
>
> I'm not sure this intersection isn't empty :/

How about we define this as EAPI=0? =)

Jokes aside, I agree with you. Features that all three package
managers have already implemented (release or beta) are quite
uninteresting. However, this will make for a more sane discussion, and
will _actually_ result in an EAPI=2 getting approved, say, in the next
Council meeting.

I say this is better than a feature-complete EAPI=2 that stays on hold
for a year because we can't collectively decide on it, results in
PM-specific overlays, loud bitching about how nothing ever gets done,
and results in overall wastage of energy.

>
> We might, however, only discuss features that all 3 package managers can
> implement easily.

I say this should be done in the context of EAPI=3 once we all agree
on what EAPI=2 should contain (let's take it slow ;)

If we start discussing EAPI=3 *now*, we _might_ get it out 6 months later[1] ;p



1. Sorry, that's how open source usually works :)
-- 
~Nirbheek Chauhan
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Doug Goldstein]

Fernando J. Pereda wrote:
>
> On 10 Jun 2008, at 18:39, Doug Goldstein wrote:
>
>> Nirbheek Chauhan wrote:
>>> On Tue, Jun 10, 2008 at 10:00 PM, Patrick Lauer
>>> <bugs@dev.gentooexperimental.org> wrote:
>>>
>>>> So EAPI 2 is not "everything shiny", but a small iterative 
>>>> improvement to
>>>> EAPI 1.
>>>>
>>>> Suggest features then and let's discuss!
>>>>
>>>
>>> For reference of existing ideas -- https://bugs.gentoo.org/174380 -- a
>>> tracker for EAPI feature requests.
>>>
>>> I personally like https://bugs.gentoo.org/197859 the most -- split out
>>> src_configure from src_compile which will allow sane resuming of
>>> compiles :)
>>>
>>>
>> At this point, we should really only discuss features that all 3 
>> package managers have implemented.
>
> I'm not sure this intersection isn't empty :/
>
> We might, however, only discuss features that all 3 package managers 
> can implement easily.
>
> - ferdy
>
That's more of what I meant.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]

On Tuesday 10 June 2008 18:26:55 Doug Goldstein wrote:
> Let's try to aim to do an EAPI=2 sometime soonish since Portage now has
> USE flag depends in version 2.2 which is looming on the horizon. It'd be
> nice to hit the ground running with supporting these. I know it'll be
> trivial for the Paludis and pkgcore guys to make this work since they
> already support USE flag depends.

I would like the portage devs to comment upon which of the following features 
they think could easily be implemented before portage 2.2 goes stable. 
There's still some time since it hasn't left package.mask yet, so I'd rather 
they exclude the features that will take too long to implement than anybody 
else doing that...

Already implemented:
- Use dependencies, it's not clear to me whether we all agree entirely upon
  the syntax yet though (bugs #2272 and #174406)

Things I believe should be trivial to implement:
- Custom output names in SRC_URI, also called arrows (bug #177863)
- Guarantee trailing slashes (bug #174408)
- Limit values in $USE (bug #176467)
- doins support for symlinks (bug #179932)
- Enable FEATURES=test by default (bug #184812)
- GLEP 42 - news items

Bigger features I'm interested in:
- Making do* die on failure by default (without changing their behaviour for
  previous eapis). Possibly adding either nonfatal or try_do* for cases where 
  this isn't desired. (bug #138792)
- More phases
  - src_prepare, for applying patches and running autotools etc.
  - src_configure, for running configure scripts (bug #197859)
  - pkg_pretend (bug #177860 - could also be used to fix bug #75936)
  - maint_*, it's not clear to me if this has been fleshed out in sufficient
    detail yet (bug #185567)
- default_*, allows an ebuild to redefine phases to add more functionality and
  then call default_$phase. Currently the default phases are lost when
  redefining the phases.
- default for src_install (bug #33544)
- Ranged dependencies (bug #4315)

Of course I'd like GLEPs 54 and 55 too but since the council still hasn't made 
a decision about them I'll leave them out..

-- 
Bo Andresen
Gentoo KDE Dev

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 3781 bytes --]

On Wed, 11 Jun 2008 00:11:32 +0200
Bo Ørsted Andresen <zlin@gentoo.org> wrote:

> On Tuesday 10 June 2008 18:26:55 Doug Goldstein wrote:
> > Let's try to aim to do an EAPI=2 sometime soonish since Portage now
> > has USE flag depends in version 2.2 which is looming on the
> > horizon. It'd be nice to hit the ground running with supporting
> > these. I know it'll be trivial for the Paludis and pkgcore guys to
> > make this work since they already support USE flag depends.
> 
> I would like the portage devs to comment upon which of the following
> features they think could easily be implemented before portage 2.2
> goes stable. There's still some time since it hasn't left
> package.mask yet, so I'd rather they exclude the features that will
> take too long to implement than anybody else doing that...

Well, actually I would rather not add any new features between pre8 and
rc1 to not further delay 2.2. And generally I'm also not in favor of
adding new features during the rc phase as it's there to eliminate
remaining bugs and for refinement of existing features, not to add new
unknowns.

> Already implemented:
> - Use dependencies, it's not clear to me whether we all agree
> entirely upon the syntax yet though (bugs #2272 and #174406)
> 
> Things I believe should be trivial to implement:
> - Custom output names in SRC_URI, also called arrows (bug #177863)

This I'd definitely delay as it probably affects a number of things.

> - Guarantee trailing slashes (bug #174408)

Mostly a matter of finding the relevant spots, the actual work to
implement it would be trivial. Could be considered as bugfix.

> - Limit values in $USE (bug #176467)

Also requires little actual work, question is only if this should be
enabled for EAPI=0/1 as well, and how it relates to USE_EXPAND and ARCH.
If it should be done for existing EAPIs as well could be considered as
bugfix.

> - doins support for symlinks (bug #179932)

If someone implements it it can be included (do you want an EAPI bump
for that?)

> - Enable FEATURES=test by default (bug #184812)

Only if >99% of the stable and ~arch tree and all potential "system"
packages build with it (IOW: no)

> - GLEP 42 - news items

Already implemented.

> Bigger features I'm interested in:
> - Making do* die on failure by default (without changing their
> behaviour for previous eapis). Possibly adding either nonfatal or
> try_do* for cases where this isn't desired. (bug #138792)
> - More phases
>   - src_prepare, for applying patches and running autotools etc.
>   - src_configure, for running configure scripts (bug #197859)
>   - pkg_pretend (bug #177860 - could also be used to fix bug #75936)
>   - maint_*, it's not clear to me if this has been fleshed out in
> sufficient detail yet (bug #185567)

Unlikely for 2.2.

> - default_*, allows an ebuild to redefine phases to add more
> functionality and then call default_$phase. Currently the default
> phases are lost when redefining the phases.

Should be trivial to implement off-hand (just converting the existing
defaults to wrappers)

> - default for src_install (bug #33544)

Should also not be terribly difficult, though I'd rather wait until
after 2.2 final.

> - Ranged dependencies (bug #4315)

Unlikely for 2.2.

> Of course I'd like GLEPs 54 and 55 too but since the council still
> hasn't made a decision about them I'll leave them out..

Well, I already said everything about those during the first discussion
round and the relevant council meeting.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 2677 bytes --]

On Wednesday 11 June 2008 01:03:47 Marius Mauch wrote:
> > I would like the portage devs to comment upon which of the following
> > features they think could easily be implemented before portage 2.2
> > goes stable. There's still some time since it hasn't left
> > package.mask yet, so I'd rather they exclude the features that will
> > take too long to implement than anybody else doing that...
>
> Well, actually I would rather not add any new features between pre8 and
> rc1 to not further delay 2.2. And generally I'm also not in favor of
> adding new features during the rc phase as it's there to eliminate
> remaining bugs and for refinement of existing features, not to add new
> unknowns.

Ok.

> > Things I believe should be trivial to implement:
> > - Custom output names in SRC_URI, also called arrows (bug #177863)
>
> This I'd definitely delay as it probably affects a number of things.

Such as?

> > - Limit values in $USE (bug #176467)
>
> Also requires little actual work, question is only if this should be
> enabled for EAPI=0/1 as well, and how it relates to USE_EXPAND and ARCH.
> If it should be done for existing EAPIs as well could be considered as
> bugfix.
>
> > - doins support for symlinks (bug #179932)
>
> If someone implements it it can be included (do you want an EAPI bump
> for that?)

Listed those here because they block the EAPI tracker bug.

> > - Enable FEATURES=test by default (bug #184812)
>
> Only if >99% of the stable and ~arch tree and all potential "system"
> packages build with it (IOW: no)

Err.. Maybe this could have been phrased better but then I did expect you 
would look at the bug before commenting. The idea is to enable tests by 
default in EAPI 2 and beyond and let them stay off by default in EAPI 0 and 
1. This way devs who want to use EAPI 2 will either have to fix their tests 
or RESTRICT them. Doing it this way avoids the issue of having to fix the 
whole tree all at once. Users can still choose not to go with the default.

> > - GLEP 42 - news items
>
> Already implemented.

And not really an EAPI issue. Hence I shouldn't have mentioned it here. ;)

> > - default_*, allows an ebuild to redefine phases to add more
> > functionality and then call default_$phase. Currently the default
> > phases are lost when redefining the phases.
>
> Should be trivial to implement off-hand (just converting the existing
> defaults to wrappers)

So that's a candidate for EAPI 2.

> > - default for src_install (bug #33544)
>
> Should also not be terribly difficult, though I'd rather wait until
> after 2.2 final.

-- 
Bo Andresen
Gentoo KDE Dev

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

On Wed, 11 Jun 2008 01:42:34 +0200
Bo Ørsted Andresen <zlin@gentoo.org> wrote:

> > > Things I believe should be trivial to implement:
> > > - Custom output names in SRC_URI, also called arrows (bug #177863)
> >
> > This I'd definitely delay as it probably affects a number of things.
> 
> Such as?

Anything that uses SRC_URI.

> > > - Enable FEATURES=test by default (bug #184812)
> >
> > Only if >99% of the stable and ~arch tree and all potential "system"
> > packages build with it (IOW: no)
> 
> Err.. Maybe this could have been phrased better but then I did expect
> you would look at the bug before commenting. The idea is to enable
> tests by default in EAPI 2 and beyond and let them stay off by
> default in EAPI 0 and 1. This way devs who want to use EAPI 2 will
> either have to fix their tests or RESTRICT them. Doing it this way
> avoids the issue of having to fix the whole tree all at once. Users
> can still choose not to go with the default.

Which means it's no longer controlled by a single FEATURES flag,
FEATURES=test means always on, while FEATURES=-test (or missing) means
always off.
Means it's not a simple switch anymore, therefore unlikely for 2.2.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]

On Wed, Jun 11, 2008 at 01:42:34AM +0200, Bo ??rsted Andresen wrote:
> On Wednesday 11 June 2008 01:03:47 Marius Mauch wrote:
> > > Things I believe should be trivial to implement:
> > > - Custom output names in SRC_URI, also called arrows (bug #177863)
> >
> > This I'd definitely delay as it probably affects a number of things.
> 
> Such as?

mirror-dist, aka the GENTOO_MIRROR infrastructure.


> > > - Limit values in $USE (bug #176467)
> >
> > Also requires little actual work, question is only if this should be
> > enabled for EAPI=0/1 as well, and how it relates to USE_EXPAND and ARCH.

eapi2 only imo, further, seems daft to limit $USE namespace while 
forcing all USE_EXPAND targets in.

Basically, IUSE should be extended to mark/state what USE_EXPAND 
namespaces it cares about- for ARCH (and friends), I'd expect they're 
pushed in regardless of IUSE.


> > > - Enable FEATURES=test by default (bug #184812)
> >
> > Only if >99% of the stable and ~arch tree and all potential "system"
> > packages build with it (IOW: no)
> 
> Err.. Maybe this could have been phrased better but then I did expect you 
> would look at the bug before commenting. The idea is to enable tests by 
> default in EAPI 2 and beyond and let them stay off by default in EAPI 0 and 
> 1. This way devs who want to use EAPI 2 will either have to fix their tests 
> or RESTRICT them. Doing it this way avoids the issue of having to fix the 
> whole tree all at once. Users can still choose not to go with the default.

This shouldn't be forced through by PM's, this should be forced 
through by communal dev agreement; I'd suggest getting that before 
trying to slide it into an eapi.

I'd prefer tests on, but I'm not convinced eapi level is the right 
area- realistically, that seems repo specifics (due to repo quality 
varying).  Either way, discussion is needed- I really doubt devs are 
going to be happy (let alone users if devs aren't careful) if they 
suddenly are forced to cleanup upstreams tests now, rather then as 
time permits.


> > > - default_*, allows an ebuild to redefine phases to add more
> > > functionality and then call default_$phase. Currently the default
> > > phases are lost when redefining the phases.
> >
> > Should be trivial to implement off-hand (just converting the existing
> > defaults to wrappers)
> 
> So that's a candidate for EAPI 2.

base_* please, rather then default; precedent is already there via 
base.eclass.  Not a hard req however, just a suggestion.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Bo Ørsted Andresen wrote:
>>> - Enable FEATURES=test by default (bug #184812)
>> Only if >99% of the stable and ~arch tree and all potential "system"
>> packages build with it (IOW: no)
> 
> Err.. Maybe this could have been phrased better but then I did expect you 
> would look at the bug before commenting.

The bug itself should be phrased better.

> The idea is to enable tests by 
> default in EAPI 2 and beyond and let them stay off by default in EAPI 0 and 
> 1. This way devs who want to use EAPI 2 will either have to fix their tests 
> or RESTRICT them. Doing it this way avoids the issue of having to fix the 
> whole tree all at once. Users can still choose not to go with the default.

People will (and should) have -test in FEATURES anyway, good self-test 
suites usually take more than twice the time to build and run, may have 
additional dependencies that could take lots of time.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

On Wed, 11 Jun 2008 06:24:18 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> People will (and should) have -test in FEATURES anyway, good
> self-test suites usually take more than twice the time to build and
> run, may have additional dependencies that could take lots of time.

So how are we supposed to handle packages where upstream *require* that
anyone building from source runs 'make check'?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Rémi Cardona]

Ciaran McCreesh a écrit :
> So how are we supposed to handle packages where upstream *require* that
> anyone building from source runs 'make check'?

If it's required to get the final binaries, then it should be in 
src_compile.

I don't know any package that does require such a thing, but IMHO it 
should be a QA warning if a build system writes anything to ${D} during 
src_test. (could sandbox be tweaked to do that?)

Rémi
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

On Wed, 11 Jun 2008 07:39:53 +0200
Rémi Cardona <remi@gentoo.org> wrote:
> Ciaran McCreesh a écrit :
> > So how are we supposed to handle packages where upstream *require*
> > that anyone building from source runs 'make check'?
> 
> If it's required to get the final binaries, then it should be in 
> src_compile.
> 
> I don't know any package that does require such a thing, but IMHO it 
> should be a QA warning if a build system writes anything to ${D}
> during src_test. (could sandbox be tweaked to do that?)

A whole bunch of science packages have upstreams that say "If you're
building from source, run 'make check' and if it fails don't carry on".

For that matter, I'm strongly inclined to say that for Paludis too...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Ciaran McCreesh wrote:
> On Wed, 11 Jun 2008 07:39:53 +0200
> Rémi Cardona <remi@gentoo.org> wrote:
>> Ciaran McCreesh a écrit :
>>> So how are we supposed to handle packages where upstream *require*
>>> that anyone building from source runs 'make check'?
>> If it's required to get the final binaries, then it should be in 
>> src_compile.
>>
>> I don't know any package that does require such a thing, but IMHO it 
>> should be a QA warning if a build system writes anything to ${D}
>> during src_test. (could sandbox be tweaked to do that?)
> 
> A whole bunch of science packages have upstreams that say "If you're
> building from source, run 'make check' and if it fails don't carry on".

Their rationale behind that is that their code is severely broken, using 
  experimental features from their language of choice or, simply, that 
they are paranoid and couldn't think better ways to annoy people?

> For that matter, I'm strongly inclined to say that for Paludis too...

Getting the build time from 30minutes to an hour or more?

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

On Wed, 11 Jun 2008 07:53:21 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> > A whole bunch of science packages have upstreams that say "If you're
> > building from source, run 'make check' and if it fails don't carry
> > on".
> 
> Their rationale behind that is that their code is severely broken,
> using experimental features from their language of choice or, simply,
> that they are paranoid and couldn't think better ways to annoy people?

Their rationale being that compilers and users screw up, and that
detecting a failure before deployment is important for people who care
about what programs do.

Simple example... Take people who use Roy's broken patches from bug
192403. If you build a program that uses C++ exception handling using
such a compiler, it'll compile just fine and then do very weird things
at runtime. Test suites catch this, and spare a lot of everyone's time.

> > For that matter, I'm strongly inclined to say that for Paludis
> > too...
> 
> Getting the build time from 30minutes to an hour or more?

And saving your ass when you're using a broken compiler that generates
broken code that would force you to reinstall a working compiler by
hand when the package manager gets h0rked.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Ciaran McCreesh wrote:
> On Wed, 11 Jun 2008 07:53:21 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>>> A whole bunch of science packages have upstreams that say "If you're
>>> building from source, run 'make check' and if it fails don't carry
>>> on".
>> Their rationale behind that is that their code is severely broken,
>> using experimental features from their language of choice or, simply,
>> that they are paranoid and couldn't think better ways to annoy people?
> 
> Their rationale being that compilers and users screw up, and that
> detecting a failure before deployment is important for people who care
> about what programs do.
> 
> Simple example... Take people who use Roy's broken patches from bug
> 192403. If you build a program that uses C++ exception handling using
> such a compiler, it'll compile just fine and then do very weird things
> at runtime. Test suites catch this, and spare a lot of everyone's time.

You are supposed to test proposed patches for opened bugs before 
deploying them in any way.

Your "example", that btw is a quite low try to smear Roy, proves nothing.

> And saving your ass when you're using a broken compiler that generates
> broken code that would force you to reinstall a working compiler by
> hand when the package manager gets h0rked.

You (upstream) are supposed to test and early users are supposed to 
check their bleeding edge stuff is working if they care enough.
People using released programs that are in stable shouldn't have to do 
that. If your code doesn't survive a gcc release usually it's the code 
being wrong most of the times.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

On Wed, 11 Jun 2008 08:50:47 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> > And saving your ass when you're using a broken compiler that
> > generates broken code that would force you to reinstall a working
> > compiler by hand when the package manager gets h0rked.
> 
> You (upstream) are supposed to test and early users are supposed to 
> check their bleeding edge stuff is working if they care enough.
> People using released programs that are in stable shouldn't have to
> do that.

If everyone running stable used the same base system, tool chain and
configuration you would be right. But every Gentoo system is different,
so there's no common target to test on. And it's fairly well
established that lots stable Gentoo users have broken toolchains...

> If your code doesn't survive a gcc release usually it's the code
> being wrong most of the times.

If you have bad code, yes. If you have good code, instead it's usually
gcc's fault. Things like gcc bug 31899 are common enough to be a
nuisance.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Santiago M. Mola]

On Wed, Jun 11, 2008 at 7:53 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
>>
>> A whole bunch of science packages have upstreams that say "If you're
>> building from source, run 'make check' and if it fails don't carry on".
>
> Their rationale behind that is that their code is severely broken, using
>  experimental features from their language of choice or, simply, that they
> are paranoid and couldn't think better ways to annoy people?
>

It's not as simple as that. A package may fail tests because compiler
bugs, build environment misconfiguration, problems in a library which
is being used, a setup problem or, of course, a bug in the package
which shows up in rare cases and haven't been spoted by upstream yet.

When the package can be critical for the system, upgrading to a buggy
version will eat people's dogs. I feel a bit safer when I run the test
phase for my package manager, and I wouldn't install it if it's
failing any test. I don't think that's too paranoid.

Also let's put a real example: gmplib. From www.gmplib.org on the front page:
" IMPORTANT INFORMATION FOR ALL GMP USERS:

GMP is very often miscompiled! We are seeing ever increasing problems
with miscompilations of the GMP code. It has now come to the point
where a compiler should be assumed to miscompile GMP. Please never use
your newly compiled libgmp.a or libgmp.so without first running make
check. If it doesn't complete without errors, don't trust the library.
Please try another compiler release, or change optimization flags
until it works. If you have the skill to isolate the problem, please
report it to us if it is a GMP bug; else to the compiler vendor. (The
compilers that cause problems are HP's unbundled compilers and GCC, in
particular Apple's GCC releases.) "

Upstream clearly states that a gmp build which tests have failed
shouldn't be used. I bet they deny support for users who fail to
follow that indication ;-)

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Santiago M. Mola wrote:
> It's not as simple as that. A package may fail tests because compiler
> bugs, build environment misconfiguration, problems in a library which
> is being used, a setup problem or, of course, a bug in the package
> which shows up in rare cases and haven't been spotted by upstream yet.

May happen indeed.

> When the package can be critical for the system, upgrading to a buggy
> version will eat people's dogs. I feel a bit safer when I run the test
> phase for my package manager, and I wouldn't install it if it's
> failing any test. I don't think that's too paranoid.

The main point is that it could be overly bothersome, if you depend on 
certain applications you won't just use the standard testsuite but also 
run your batch of compliance checks, but that isn't common.


> Upstream clearly states that a gmp build which tests have failed
> shouldn't be used. I bet they deny support for users who fail to
> follow that indication ;-)

gmp isn't a key component if you aren't using math/sci applications 
using it. You may point openssl as something you may want to have a 
round of checks before is too late, same for openssh.

Still there are people perfectly happy w/out those since they do not use 
those packages that for me and possibly many other are vital.

I won't be happy to have gcc have its batch of tests run, just to see 
later it fails on ffmpeg because the tests do not catch those 
conditions, I have better way to break gcc than those you have in the 
regression test =/

Changing the default features would just at best have people that do not 
care switch to -test, people that care already about that won't be 
affected and just create an annoyance.

Putting it in an eapi makes not much sense as well since you may change 
the defaults as you wish since they aren't causing incompatibilities.

To sum up:
- having the test feature on by default isn't good for anybody but 
paranoids and lazy developers, paranoids have that already on, lazy 
developers will switch it off for them and let people do the automated 
test for them.
- having that mandated by the eapi doesn't have sense since it doesn't 
change anything by itself.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: EAPI-2 - Let's get it started

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

On Wed, 11 Jun 2008 14:20:03 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> Santiago M. Mola wrote:
> > Upstream clearly states that a gmp build which tests have failed
> > shouldn't be used. I bet they deny support for users who fail to
> > follow that indication ;-)
> 
> gmp isn't a key component if you aren't using math/sci applications 
> using it. You may point openssl as something you may want to have a 
> round of checks before is too late, same for openssh.

Minor nit:  GMP is a requirement to build GCC >=4.3, so it'll be a key
component soon enough.

> Changing the default features would just at best have people that do
> not care switch to -test, people that care already about that won't
> be affected and just create an annoyance.
> 
> Putting it in an eapi makes not much sense as well since you may
> change the defaults as you wish since they aren't causing
> incompatibilities.
> 
> To sum up:
> - having the test feature on by default isn't good for anybody but 
> paranoids and lazy developers, paranoids have that already on, lazy 
> developers will switch it off for them and let people do the
> automated test for them.
> - having that mandated by the eapi doesn't have sense since it
> doesn't change anything by itself.

Fully in agreement.

-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Peter Volkov]

В Срд, 11/06/2008 в 07:53 +0200, Luca Barbato пишет:
> Getting the build time from 30minutes to an hour or more?

Actually I don't understand this concern. If you bother about time
tests take don't build package from sources - use binary packages. If
you build program by yourself - run testsuite to be sure it was built
correctly in your environment...

-- 
Peter.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Ciaran McCreesh wrote:
> On Wed, 11 Jun 2008 06:24:18 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> People will (and should) have -test in FEATURES anyway, good
>> self-test suites usually take more than twice the time to build and
>> run, may have additional dependencies that could take lots of time.
> 
> So how are we supposed to handle packages where upstream *require* that
> anyone building from source runs 'make check'?

Spank them as we already do for people building their test as part of 
the default target.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On Wed, 11 Jun 2008 07:48:06 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 11 Jun 2008 06:24:18 +0200
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >> People will (and should) have -test in FEATURES anyway, good
> >> self-test suites usually take more than twice the time to build and
> >> run, may have additional dependencies that could take lots of time.
> > 
> > So how are we supposed to handle packages where upstream *require*
> > that anyone building from source runs 'make check'?
> 
> Spank them as we already do for people building their test as part of 
> the default target.

Oh, so Gentoo has decided that basic QA is another 'poor programming
practice' now?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Ciaran McCreesh wrote:
> Oh, so Gentoo has decided that basic QA is another 'poor programming
> practice' now?

Having a good testsuite is part of the QA, having it not failing is part 
of the QA, running it for supposedly tested code (thus having those test 
passed already) every time isn't.

People marking stuff ~ or stable should run the testsuite as a way to 
make sure the package is sound. Users shouldn't take this pain.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

On Wed, 11 Jun 2008 07:58:44 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > Oh, so Gentoo has decided that basic QA is another 'poor programming
> > practice' now?
> 
> Having a good testsuite is part of the QA, having it not failing is
> part of the QA, running it for supposedly tested code (thus having
> those test passed already) every time isn't.

You assume that users have working, properly configured compilers. It's
fairly well established that a lot of them don't, particularly on
Gentoo.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Ciaran McCreesh wrote:
> You assume that users have working, properly configured compilers. It's
> fairly well established that a lot of them don't, particularly on
> Gentoo.

"if your code sucks isn't our fault." - gcc upstream

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 433 bytes --]

On Wed, 11 Jun 2008 08:57:35 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > You assume that users have working, properly configured compilers.
> > It's fairly well established that a lot of them don't, particularly
> > on Gentoo.
> 
> "if your code sucks isn't our fault." - gcc upstream

And those all too common cases where the code is correct and gcc gets
it wrong?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Ciaran McCreesh wrote:
> On Wed, 11 Jun 2008 08:57:35 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>>> You assume that users have working, properly configured compilers.
>>> It's fairly well established that a lot of them don't, particularly
>>> on Gentoo.
>> "if your code sucks isn't our fault." - gcc upstream
> 
> And those all too common cases where the code is correct and gcc gets
> it wrong?

Get fixed.

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

On Wed, 11 Jun 2008 09:14:03 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 11 Jun 2008 08:57:35 +0200
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >> Ciaran McCreesh wrote:
> >>> You assume that users have working, properly configured compilers.
> >>> It's fairly well established that a lot of them don't,
> >>> particularly on Gentoo.
> >> "if your code sucks isn't our fault." - gcc upstream
> > 
> > And those all too common cases where the code is correct and gcc
> > gets it wrong?
> 
> Get fixed.

And all those people running gcc versions that haven't had the fix
applied yet?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: EAPI-2 - Let's get it started

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

On Wed, 11 Jun 2008 01:42:34 +0200
Bo Ørsted Andresen <zlin@gentoo.org> wrote:
> Err.. Maybe this could have been phrased better but then I did expect
> you would look at the bug before commenting. The idea is to enable
> tests by default in EAPI 2 and beyond and let them stay off by
> default in EAPI 0 and 1. This way devs who want to use EAPI 2 will
> either have to fix their tests or RESTRICT them. Doing it this way
> avoids the issue of having to fix the whole tree all at once. Users
> can still choose not to go with the default.

if people are just going to RESTRICT tests when they fail (and they
will, because it's a hell of a lot easier than actually fixing them),
what's the point of having a testsuite at all? and once a testsuite is
restricted, it'll stay restricted even if upstream fixes the problem
because no one will bother checking. the time needed for
testsuites can be substantial.  (auto{make,conf} can take half an hour
to run the tests on a fast machine (compared to the total compile
and install time of 10 seconds). the build time for gcc triples.) they
can pull in a large number of dependencies. etc, etc.

as i mentioned on the bug, i'd like to see something like
FEATURES=dev that would enable tests by default, turn on those QA
source code warnings, maybe some of the stuff from stricter, and other
things that our users don't really need but are important to us.

anyways, just my opinion.

> Users can still choose not to go with the default.

so can devs, and they outnumber us. ;)


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On Tue, 10 Jun 2008 23:16:04 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> if people are just going to RESTRICT tests when they fail (and they
> will, because it's a hell of a lot easier than actually fixing them),
> what's the point of having a testsuite at all? and once a testsuite is
> restricted, it'll stay restricted even if upstream fixes the problem
> because no one will bother checking.

You're assuming that developers are lazy, incompetent and don't care
about QA. If this isn't the case, developers will instead fix or remove
individual test failures where reasonably possible, and will unrestrict
tests when doing version bumps.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: EAPI-2 - Let's get it started

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

On Wed, 11 Jun 2008 06:19:16 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 10 Jun 2008 23:16:04 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
> > if people are just going to RESTRICT tests when they fail (and they
> > will, because it's a hell of a lot easier than actually fixing
> > them), what's the point of having a testsuite at all? and once a
> > testsuite is restricted, it'll stay restricted even if upstream
> > fixes the problem because no one will bother checking.
> 
> You're assuming that developers are lazy, incompetent and don't care
> about QA.

Historically speaking, yes.  Well, one and three at least. ;)

> If this isn't the case, developers will instead fix or
> remove individual test failures where reasonably possible, and will
> unrestrict tests when doing version bumps.

That would be awesome, and i'd love to be proven wrong.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Alexis Ballier]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

On Wed, 11 Jun 2008 01:42:34 +0200
Bo Ørsted Andresen <zlin@gentoo.org> wrote:

> > > - Enable FEATURES=test by default (bug #184812)
> >
> > Only if >99% of the stable and ~arch tree and all potential "system"
> > packages build with it (IOW: no)
> 
> Err.. Maybe this could have been phrased better but then I did expect
> you would look at the bug before commenting. The idea is to enable
> tests by default in EAPI 2 and beyond and let them stay off by
> default in EAPI 0 and 1. This way devs who want to use EAPI 2 will
> either have to fix their tests or RESTRICT them. Doing it this way
> avoids the issue of having to fix the whole tree all at once. Users
> can still choose not to go with the default.

I thought tests were already supposed to pass whatever the EAPI is and
devs were supposed to run them...


Alexis.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

On Wed, 11 Jun 2008 07:49:44 +0200
Alexis Ballier <aballier@gentoo.org> wrote:
> I thought tests were already supposed to pass whatever the EAPI is and
> devs were supposed to run them...

Supposedly. But in practice this isn't true, because far too many
developers just don't care.

The whole mess started because src_test was introduced late on, but
before EAPIs, so there was no incremental way of making tests usable.
Enforcing src_test in a "you must explicitly say so if your package's
test suites are expected to fail" way on an EAPI bump is a clean way of
recovering from this.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Ciaran McCreesh wrote:
> On Wed, 11 Jun 2008 07:49:44 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
>> I thought tests were already supposed to pass whatever the EAPI is and
>> devs were supposed to run them...
> 
> Supposedly. But in practice this isn't true, because far too many
> developers just don't care.

and having it forced in the eapi won't change this.

> Enforcing src_test in a "you must explicitly say so if your package's
> test suites are expected to fail" way on an EAPI bump is a clean way of
> recovering from this.

You are assuming that every package has a test (false), nobody will have 
src_test dummified.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

On Wed, 11 Jun 2008 08:01:30 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 11 Jun 2008 07:49:44 +0200
> > Alexis Ballier <aballier@gentoo.org> wrote:
> >> I thought tests were already supposed to pass whatever the EAPI is
> >> and devs were supposed to run them...
> > 
> > Supposedly. But in practice this isn't true, because far too many
> > developers just don't care.
> 
> and having it forced in the eapi won't change this.

Sure it will. They won't be able to install their package without
either passing src_test or restricting it.

Developers *do* try to install things before committing, right?

> > Enforcing src_test in a "you must explicitly say so if your
> > package's test suites are expected to fail" way on an EAPI bump is
> > a clean way of recovering from this.
> 
> You are assuming that every package has a test (false), nobody will
> have src_test dummified.

Not at all. If upstream has no test suite, or developers choose to
RESTRICT off test, it just means there's less QA being done for that
package.

But more importantly, it still means that people *know* that a failing
src_test is to be investigated. Currently they instead have to guess
whether it's a lazy developer issue or a genuine bug being shown.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Ciaran McCreesh wrote:
> Sure it will. They won't be able to install their package without
> either passing src_test or restricting it.
> 
> Developers *do* try to install things before committing, right?

No, they also write the ebuilds using cat /dev/urandom through a perl 
regexp.

> But more importantly, it still means that people *know* that a failing
> src_test is to be investigated. Currently they instead have to guess
> whether it's a lazy developer issue or a genuine bug being shown.

Not really.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

On Wed, 11 Jun 2008 08:55:16 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> > But more importantly, it still means that people *know* that a
> > failing src_test is to be investigated. Currently they instead have
> > to guess whether it's a lazy developer issue or a genuine bug being
> > shown.
> 
> Not really.

Ok, if EAPI 2 turns on src_test except where explicitly overridden by
the ebuild, explain how EAPI 2 src_test failures are meaningless in the
same way that EAPI 0/1 src_test failures are.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Luca Barbato]

Ciaran McCreesh wrote:
> Ok, if EAPI 2 turns on src_test except where explicitly overridden by
> the ebuild, explain how EAPI 2 src_test failures are meaningless in the
> same way that EAPI 0/1 src_test failures are.

Test failures aren't meaningless right now. Applications with good test 
suites got them used by the people that cares already.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

On Wed, 11 Jun 2008 09:18:07 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > Ok, if EAPI 2 turns on src_test except where explicitly overridden
> > by the ebuild, explain how EAPI 2 src_test failures are meaningless
> > in the same way that EAPI 0/1 src_test failures are.
> 
> Test failures aren't meaningless right now. Applications with good
> test suites got them used by the people that cares already.

The point you've been missing this whole time:

If, as a user or an arch person, I get a src_test failure right now, I
don't know whether this means "eek! Something's gone wrong, and I
really need to fix this" or "oh, whoever maintains this package
doesn't care". But with EAPI 2, I'll be able to know that a src_test
failure really does mean "something's wrong".

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Matthias Langer]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]


> If, as a user or an arch person, I get a src_test failure right now, I
> don't know whether this means "eek! Something's gone wrong, and I
> really need to fix this" or "oh, whoever maintains this package
> doesn't care". But with EAPI 2, I'll be able to know that a src_test
> failure really does mean "something's wrong".
> 

A developer should always care about src_test in my opinion. That some
developers don't is a nuisance, and the core of the problem. But trying
to change this via EAPI is doing things the wrong way round: At first
there has to be an agreement about the importance of test suites (backed
up by strict policies that every developer is bound to), and then we can
discuss if it makes sense to activate them by default in EAPI-X. 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Richard Brown]

On Wed, Jun 11, 2008 at 08:18, Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
>>
>> Ok, if EAPI 2 turns on src_test except where explicitly overridden by
>> the ebuild, explain how EAPI 2 src_test failures are meaningless in the
>> same way that EAPI 0/1 src_test failures are.
>
> Test failures aren't meaningless right now. Applications with good test
> suites got them used by the people that cares already.

If you care about tests now, how do you know if foo.ebuild failed its
src_test because there's a problem or if src_test failed because no
one else has ever run it with test in FEATURES?

Also, I think you seem to be suggesting that gentoo is so well tested
that once something's marked stable, there's no point in testing it.

-- 
Richard Brown
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Thomas Anderson]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

On Wed, Jun 11, 2008 at 08:23:59AM +0100, Richard Brown wrote:
> Also, I think you seem to be suggesting that gentoo is so well tested
> that once something's marked stable, there's no point in testing it.

A very good point. Just last week the *stable* perl cairo bindings were
broken by a x11-libs/cairo bump. We caught this however and noticed that
the new perl cairo bindings worked. Those were then stabilized at the
same time and users now have a working cairo.

What would have happened if that hadn't happened? Any package that
depended on dev-perl/Cairo would've been broken.

The lesson to learn is that once something is stable doesn't mean it's
always stable. If a user finds out that way and files a bug, chances are
greater that he'll get a dev-perl/Cairo that works with the new cairo
version soon, rather than a dev-perl/Cairo version that breaks
immediately.

What would you rather have?

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Donnie Berkholz]

On 00:11 Wed 11 Jun     , Bo Ørsted Andresen wrote:
> I would like the portage devs to comment upon which of the following features 
> they think could easily be implemented before portage 2.2 goes stable. 

These ones meet the criteria of "I know people are working around them 
because they don't exist yet, and it's annoying and extra work":

> - Use dependencies, it's not clear to me whether we all agree entirely upon
>   the syntax yet though (bugs #2272 and #174406)
> - Custom output names in SRC_URI, also called arrows (bug #177863)
> - Limit values in $USE (bug #176467)
> - GLEP 42 - news items
>   - maint_*, it's not clear to me if this has been fleshed out in sufficient
>     detail yet (bug #185567)
> - default_*, allows an ebuild to redefine phases to add more functionality and
>   then call default_$phase. Currently the default phases are lost when
>   redefining the phases.
> - default for src_install (bug #33544)
> - Ranged dependencies (bug #4315)

Thanks,
Donnie
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2490 bytes --]

On Tue, Jun 10, 2008 at 12:26:55PM -0400, Doug Goldstein wrote:
> Let's try to aim to do an EAPI=2 sometime soonish since Portage now has 
> USE flag depends in version 2.2 which is looming on the horizon. It'd be 
> nice to hit the ground running with supporting these. I know it'll be 
> trivial for the Paludis and pkgcore guys to make this work since they 
> already support USE flag depends.

The relevant bugs that should go into eapi2-

bug 211529 (econf == configure --disable-dependency-tracking 
  --enable-fast-install)
bug 205557 (export var/api indicating what sort of op this is- 
  replace, install, uninstall, for pkg_*)
bug 203891: STRIP_MASK; this would allow ebuilds to be fully unaware 
  of the strip implementation, although would require the var to be 
  in binpkg metadata (pkgcore specific request, since we allow 
  stripping of unstripped binpkgs)
bug 199722: use/useq; nail it down to one or the other imo.

Not bugged, but potentials for minor cleanup:
* drop AA (basically unused)
* drop RDEPEND=${RDEPEND-${DEPEND}}, unless there is a strong arg to 
  keep it (I recall a historical strong arg to punt it)
* identify any remaining portageq additions needed to allow 
  /var/db/pkg to change format

From the "proposed way back when but never got off the ground":
* USE mutually exclusive representation; fancy way of moving code like
 use foon && use !blah && die "blah must be enabled if foon is enabled"
 into a form that can be detected up front, instead of going 'boom' at 
 pkg_setup time.  This was originally proposed to address USE 
 configurations states for php pkgs, quick look, it still could be 
 useful.  Would be implemented via a new metadata key most likely.


Finally; it needs updating, but glep33 
(http://glep.gentoo.org/glep-0033.html) I'd be interested in trying to 
get into eapi2.  Currently, all managers support some form of env 
saving/restoration that the glep required, so that dependency is gone.  

What remains is basically updating the glep (I can do so), council 
agreement (presume non issue), and implementation- easy for pkgcore, 
presumably easy enough for paludis, easy for portage (already asked 
zac).

If glep33 went in, I'd suggest bug 197859: split 
src_configure/src_compile .  Without g33, holding off on 
src_configure/src_compile would likely be wise since it introduces 
some potentially nasty eapi related issues in eclasses.

Comments welcome.
~harring


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]