[gentoo-dev] [RFC] What features should be included in EAPI 2?

[gentoo-dev] [RFC] What features should be included in EAPI 2?

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello again,

I'd like to get some feedback about what people would like to have
in the final EAPI 2. In planning for this EAPI bump, we should
strike a balance somewhere in between everything that we'd like to
have and whatever we can implement in a short period of time. It
doesn't really makes sense to delay the EAPI bump too much for
implementation of new features, since those features can simply be
reserved for a future EAPI bump.

The latest experiment EAPI is 2_pre2, supported by
>=sys-apps/portage-2.2_rc7. Please refer to the html documentation
[1] for addition information about the experimental EAPI extensions
which are summarized here:

 * The 'doman' helper function recognizes language codes in man page
   source files, and uses them to generate an appropriate
   installation path.

 * Dependency atoms can be constrained to match specific USE flag
   states, including USE conditional expressions embedded within
   the atoms themselves.

 * The old src_compile phase function is split into separate
   src_configure and src_compile fuctions.

 * Default phase function implementations for the current EAPI are
   accessible via a function having a name that begins with default_
   and ends with the respective phase function name.

 * Default phase function implementations for older EAPIs are
   accessible via functions having names that start with 'eapi',
   followed by the EAPI value.

 * The default phase function implementation for the currently
   executing phase is accessible as a function named 'default'.

In addition to the above extensions, I've received a patch for
SRC_URI arrows [2] that I plan to review but haven't had time yet.
Please file bugs for any additional features that you'd like to add
and mark them as blockers of bug 174380 [3].

Thanks,
Zac

[1]
http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi
[2] http://bugs.gentoo.org/show_bug.cgi?id=177863
[3] http://bugs.gentoo.org/show_bug.cgi?id=174380
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiimNgACgkQ/ejvha5XGaOsCwCfYBAJNwTcl7USG/OF4lxI5iND
nD8An1lfyS6f5lvqXgeA1bXB3JHstyIi
=NGBs
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] What features should be included in EAPI 2?

[Ciaran McCreesh]

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

On Wed, 13 Aug 2008 01:18:33 -0700
Zac Medico <zmedico@gentoo.org> wrote:
>  * The old src_compile phase function is split into separate
>    src_configure and src_compile fuctions.

If you're doing new phases... Exheres has been using src_prepare, after
src_unpack, to avoid having lots of things of the form:

src_unpack() {
    default
    patch blah
    eautoreconf
}

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] [RFC] What features should be included in EAPI 2?

[Petteri Räty]

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

Zac Medico kirjoitti:
> 
>  * Default phase function implementations for older EAPIs are
>    accessible via functions having names that start with 'eapi',
>    followed by the EAPI value.
> 

What's the benefit of this feature?

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] [RFC] What features should be included in EAPI 2?

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Wed, 13 Aug 2008 01:18:33 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>>  * The old src_compile phase function is split into separate
>>    src_configure and src_compile fuctions.
> 
> If you're doing new phases... Exheres has been using src_prepare, after
> src_unpack, to avoid having lots of things of the form:
> 
> src_unpack() {
>     default
>     patch blah
>     eautoreconf
> }
> 

Thanks, that seems like a useful extension.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkijS/sACgkQ/ejvha5XGaMj4gCfVkfggl6JCAIW9JJkT3Izt9Hr
T3oAoI3RIMTnpaZXxebZhfjZspHhhb/j
=6Wzp
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] What features should be included in EAPI 2?

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Petteri Räty wrote:
> Zac Medico kirjoitti:
>>
>>  * Default phase function implementations for older EAPIs are
>>    accessible via functions having names that start with 'eapi',
>>    followed by the EAPI value.
>>
> 
> What's the benefit of this feature?

In some cases it might be convenient or desirable to use a phase
implementation from an older EAPI. However, I'm not sure how often
this will be useful, if ever. I added it at the suggestion of Brian
Harring.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkijTRsACgkQ/ejvha5XGaM5+wCg0eJBUMWNDQYcYRMZ9ecYSfGX
XUEAoMmRU4sdRUA+4oU61fFHWADzKLUw
=M0lq
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] What features should be included in EAPI 2?

[Petteri Räty]

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

Zac Medico kirjoitti:
> Petteri Räty wrote:
>> Zac Medico kirjoitti:
>>>  * Default phase function implementations for older EAPIs are
>>>    accessible via functions having names that start with 'eapi',
>>>    followed by the EAPI value.
>>>
>> What's the benefit of this feature?
> 
> In some cases it might be convenient or desirable to use a phase
> implementation from an older EAPI. However, I'm not sure how often
> this will be useful, if ever. I added it at the suggestion of Brian
> Harring.
> 
> Zac

I wouldn't add things unless someone has a use case for it.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[gentoo-dev] Re: [RFC] What features should be included in EAPI 2?

[Steve Long]

Ciaran McCreesh wrote:

> On Wed, 13 Aug 2008 01:18:33 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>>  * The old src_compile phase function is split into separate
>>    src_configure and src_compile fuctions.
> 
> If you're doing new phases... Exheres has been using src_prepare, after
> src_unpack, to avoid having lots of things of the form:
> 
> src_unpack() {
>     default
>     patch blah
>     eautoreconf
> }
> 
Besides saving one line of typing, what is the benefit of adding this new
phase?

Re: [gentoo-dev] Re: [RFC] What features should be included in EAPI 2?

[Ciaran McCreesh]

On Tue, Aug 19, 2008 at 12:12 PM, Steve Long
<slong@rathaus.eclipse.co.uk> wrote:
> Ciaran McCreesh wrote:
>> If you're doing new phases... Exheres has been using src_prepare, after
>> src_unpack, to avoid having lots of things of the form:
>>
>> src_unpack() {
>>     default
>>     patch blah
>>     eautoreconf
>> }
>>
> Besides saving one line of typing, what is the benefit of adding this new
> phase?

Uh, count again. It's not just one line of typing saved.

The benefit is that it's a logically separate action, and will avoid
all the silliness of people repeatedly changing their minds about
which phase should do the eautoreconf calls and so on.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [RFC] What features should be included in EAPI 2?

[Arun Raghavan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
[...]
> The benefit is that it's a logically separate action, and will avoid
> all the silliness of people repeatedly changing their minds about
> which phase should do the eautoreconf calls and so on.

a) Is this really an issue for maintainers?

b) Does it really matter?

c) So the flow will look like:

...
src_unpack
src_prepare
src_configure
src_compile
...

To me this seems like an unnecessary overgeneralisation. The *only*
potential "benefit" I see here is that at some point of time in the
nebulous future, it might be possible to tell the PM to always skip
src_prepare in order to give a system where everything is "vanilla".

This is not something I see as being useful to us.

- -- Arun
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkirCm0ACgkQ+Vqt1inD4uyTvQCgjEPHRCJUFrIsoyk5EnYb/jNC
Lu8An0KTbHP59UXa4UcShSC7VwLUgQpI
=zwPv
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [RFC] What features should be included in EAPI 2?

[Ciaran McCreesh]

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

On Tue, 19 Aug 2008 23:31:17 +0530
Arun Raghavan <ford_prefect@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > The benefit is that it's a logically separate action, and will avoid
> > all the silliness of people repeatedly changing their minds about
> > which phase should do the eautoreconf calls and so on.
> 
> a) Is this really an issue for maintainers?

It's not a huge issue, any more than src_configure is. Equally, it's not
expensive to implement.

> b) Does it really matter?

In the grand scheme of things, no. In the grand scheme of things, you
only *need* a single src_ function. From a maintainer convenience
perspective, however, src_prepare is marginally more useful than having
a split src_configure.

> c) So the flow will look like:
> 
> ...
> src_unpack
> src_prepare
> src_configure
> src_compile
> ...
> 
> To me this seems like an unnecessary overgeneralisation.

It's a better mapping of the things ebuilds do than the current set of
functions.

The logic is this: lots of ebuilds end up duplicating src_unpack (or,
in future EAPIs, calling 'default') and then adding things to do
preparation work. Experience suggests that the most common reason for
overriding src_unpack is to do preparation work, not to change how
things are unpacked.

(Number-wise... For Exherbo, where the split's already been made,
custom src_prepare functions are three times more common than custom
src_unpack functions. And that figure's significantly lower than what
Gentoo would see, because with exheres-0 'default' functions you don't
need to write a src_prepare if you're merely applying patches.)

> The *only* potential "benefit" I see here is that at some point of
> time in the nebulous future, it might be possible to tell the PM to
> always skip src_prepare in order to give a system where everything is
> "vanilla".

Such a system wouldn't be usable... Not all of Gentoo's patches are
non-essential.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: Re: [RFC] What features should be included in EAPI 2?

[Steve Long]

Ciaran McCreesh wrote:

> On Tue, 19 Aug 2008 23:31:17 +0530
> Arun Raghavan <ford_prefect@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>> > The benefit is that it's a logically separate action, and will avoid
>> > all the silliness of people repeatedly changing their minds about
>> > which phase should do the eautoreconf calls and so on.
Er, that would be the new src_configure?

>> 
>> a) Is this really an issue for maintainers?
> 
> It's not a huge issue, any more than src_configure is. Equally, it's not
> expensive to implement.
> 
>> b) Does it really matter?
> 
> In the grand scheme of things, no. In the grand scheme of things, you
> only *need* a single src_ function. From a maintainer convenience
> perspective, however, src_prepare is marginally more useful than having
> a split src_configure.
>
How so?

From a user point of view, and from a maintenance point of view,
src_configure is very useful.
 
>> c) So the flow will look like:
>> 
>> ...
>> src_unpack
>> src_prepare
>> src_configure
>> src_compile
>> ...
>> 
>> To me this seems like an unnecessary overgeneralisation.
> 
> It's a better mapping of the things ebuilds do than the current set of
> functions.
> 
> The logic is this: lots of ebuilds end up duplicating src_unpack (or,
> in future EAPIs, calling 'default') and then adding things to do
> preparation work. Experience suggests that the most common reason for
> overriding src_unpack is to do preparation work, not to change how
> things are unpacked.
>
Yeah I've always seen src_unpack as being more cogent to preparation of src
files, than to actually untarring stuff. So what? Why make a new phase
which every new dev has to know about, and we have to provide pre_ and
post_ hooks for, when the existing phase covers the usage fine?
 
> (Number-wise... For Exherbo, where the split's already been made,
> custom src_prepare functions are three times more common than custom
> src_unpack functions. And that figure's significantly lower than what
> Gentoo would see, because with exheres-0 'default' functions you don't
> need to write a src_prepare if you're merely applying patches.)
>
Well it's easy enough to auto-apply patches, given a declaration in the
ebuild (since files for all versions are in the same dir.) It certainly
doesn't need a new phase.
 
>> The *only* potential "benefit" I see here is that at some point of
>> time in the nebulous future, it might be possible to tell the PM to
>> always skip src_prepare in order to give a system where everything is
>> "vanilla".
> 
> Such a system wouldn't be usable... Not all of Gentoo's patches are
> non-essential.
> 
So the real, fully-defined, explicit benefit is..

Re: [gentoo-dev] Re: Re: [RFC] What features should be included in EAPI 2?

[Ciaran McCreesh]

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

On Tue, 19 Aug 2008 21:27:03 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > On Tue, 19 Aug 2008 23:31:17 +0530
> > Arun Raghavan <ford_prefect@gentoo.org> wrote:
> >> Ciaran McCreesh wrote:
> >> > The benefit is that it's a logically separate action, and will
> >> > avoid all the silliness of people repeatedly changing their
> >> > minds about which phase should do the eautoreconf calls and so
> >> > on.
> Er, that would be the new src_configure?

Oh really?

> > In the grand scheme of things, no. In the grand scheme of things,
> > you only *need* a single src_ function. From a maintainer
> > convenience perspective, however, src_prepare is marginally more
> > useful than having a split src_configure.
> >
> How so?
> 
> From a user point of view, and from a maintenance point of view,
> src_configure is very useful.

Any reason you can provide for src_configure being useful can be used
with slight modification for src_prepare.

> > It's a better mapping of the things ebuilds do than the current set
> > of functions.
> > 
> > The logic is this: lots of ebuilds end up duplicating src_unpack
> > (or, in future EAPIs, calling 'default') and then adding things to
> > do preparation work. Experience suggests that the most common
> > reason for overriding src_unpack is to do preparation work, not to
> > change how things are unpacked.
> >
> Yeah I've always seen src_unpack as being more cogent to preparation
> of src files, than to actually untarring stuff.

Yes, the 'unpack' in the name really does go along with the phase being
used to prepare things.

> So what? Why make a new phase which every new dev has to know about,
> and we have to provide pre_ and post_ hooks for, when the existing
> phase covers the usage fine? 

Make a phase for each common logically distinct operation. Which, with
src_prepare being added, we almost have.

(The one missing is a src_fetch_extra or somesuch, for use by the scm
eclasses. But that wants special handling, and is probably best left to
another EAPI...)

> > (Number-wise... For Exherbo, where the split's already been made,
> > custom src_prepare functions are three times more common than custom
> > src_unpack functions. And that figure's significantly lower than
> > what Gentoo would see, because with exheres-0 'default' functions
> > you don't need to write a src_prepare if you're merely applying
> > patches.)
> >
> Well it's easy enough to auto-apply patches, given a declaration in
> the ebuild (since files for all versions are in the same dir.) It
> certainly doesn't need a new phase.

Well, if you're proposing that Gentoo also adopts the more complicated
default_* functions from exheres-0, you're more than welcome to write
up a proposal...

> >> The *only* potential "benefit" I see here is that at some point of
> >> time in the nebulous future, it might be possible to tell the PM to
> >> always skip src_prepare in order to give a system where everything
> >> is "vanilla".
> > 
> > Such a system wouldn't be usable... Not all of Gentoo's patches are
> > non-essential.
> > 
> So the real, fully-defined, explicit benefit is..

The same as the benefit of splitting src_compile into src_configure and
src_compile, except that it'll be of use to a slightly larger
proportion of ebuilds.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: Re: Re: [RFC] What features should be included in EAPI 2?

[Steve Long]

Ciaran McCreesh wrote:

> On Tue, 19 Aug 2008 21:27:03 +0100
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> > On Tue, 19 Aug 2008 23:31:17 +0530
>> > Arun Raghavan <ford_prefect@gentoo.org> wrote:
>> >> Ciaran McCreesh wrote:
>> >> > The benefit is that it's a logically separate action, and will
>> >> > avoid all the silliness of people repeatedly changing their
>> >> > minds about which phase should do the eautoreconf calls and so
>> >> > on.
>> Er, that would be the new src_configure?
> 
> Oh really?
>
Hmm fun as it isn't playing these games with you..
 
>> > In the grand scheme of things, no. In the grand scheme of things,
>> > you only *need* a single src_ function. From a maintainer
>> > convenience perspective, however, src_prepare is marginally more
>> > useful than having a split src_configure.
>> >
>> How so?
>> 
>> From a user point of view, and from a maintenance point of view,
>> src_configure is very useful.
> 
> Any reason you can provide for src_configure being useful can be used
> with slight modification for src_prepare.
>
Which is no reason to add a new phase. OFC if zac wants to provide it that's
entirely up to him.
 
>> > It's a better mapping of the things ebuilds do than the current set
>> > of functions.
>> > 
>> > The logic is this: lots of ebuilds end up duplicating src_unpack
>> > (or, in future EAPIs, calling 'default') and then adding things to
>> > do preparation work. Experience suggests that the most common
>> > reason for overriding src_unpack is to do preparation work, not to
>> > change how things are unpacked.
>> >
>> Yeah I've always seen src_unpack as being more cogent to preparation
>> of src files, than to actually untarring stuff.
> 
> Yes, the 'unpack' in the name really does go along with the phase being
> used to prepare things.
>
Oh so this is about correct nomenclature rather than anything else? I see.
 
>> So what? Why make a new phase which every new dev has to know about,
>> and we have to provide pre_ and post_ hooks for, when the existing
>> phase covers the usage fine?
> 
> Make a phase for each common logically distinct operation. Which, with
> src_prepare being added, we almost have.
>
Yes, I see, because it's really needed; real functionality our users have
been crying out for.
 
> (The one missing is a src_fetch_extra or somesuch, for use by the scm
> eclasses. But that wants special handling, and is probably best left to
> another EAPI...)
>
Yes, a defined, configurable API for dealing with any version control would
be useful, though your minion seemed to argue against it in #-portage. I
can think of a couple of things that would be more useful to end-users:
pkg_check for interactive ebuilds (eg license acceptance or media access),
proper support for cross-compiling, integration of prefix, better handling
of overlays, and of binpkgs..
 
>> > (Number-wise... For Exherbo, where the split's already been made,
>> > custom src_prepare functions are three times more common than custom
>> > src_unpack functions. And that figure's significantly lower than
>> > what Gentoo would see, because with exheres-0 'default' functions
>> > you don't need to write a src_prepare if you're merely applying
>> > patches.)
>> >
>> Well it's easy enough to auto-apply patches, given a declaration in
>> the ebuild (since files for all versions are in the same dir.) It
>> certainly doesn't need a new phase.
> 
> Well, if you're proposing that Gentoo also adopts the more complicated
> default_* functions from exheres-0, you're more than welcome to write
> up a proposal...
>
Tsk of course not. default functions are in the pipeline in any case, but
glad to see you're still using this list for proselytising your pet project
while avoiding true discussion. In any event, it wouldn't be needed.
 
>> >> The *only* potential "benefit" I see here is that at some point of
>> >> time in the nebulous future, it might be possible to tell the PM to
>> >> always skip src_prepare in order to give a system where everything
>> >> is "vanilla".
>> > 
>> > Such a system wouldn't be usable... Not all of Gentoo's patches are
>> > non-essential.
>> > 
>> So the real, fully-defined, explicit benefit is..
> 
> The same as the benefit of splitting src_compile into src_configure and
> src_compile, except that it'll be of use to a slightly larger
> proportion of ebuilds.
> 
As ever, you fail to argue the actual case, preferring to hide behind "the
same reasons as.." which is a variant on the "if you don't understand some
one line comment, you're not qualified to discuss anything (plus you're
ugly.)"

The reasoning others have given (yes it is possible to explain why without
making people read thru 20 one line emails) is that this would be useful
for live ebuilds. In maintenance terms (when looking at the lifecycle of an
ebuild) I don't see the need, since there is no unpacking required from a
vcs pull. Once it's made into a normal ebuild, any preparation would
necessarily require review and might not be needed at all.

Call the function what you like (or add a new phase with the hooks) it's
still logically one point in time. For a live ebuild it's to prepare the
src, for a normal one to (possibly) unpack and prepare.

src_configure is a logically distinct action which warrants a new phase,
since the e*conf call in compile makes retrying a long build (without
having to recompile stuff which doesn't need it) much more difficult; its
absence prevents full use of make. Prepare does not warrant a new phase imo
since it should only be run once per compilation instance; anything it does
can either be done in unpack, or in configure should that be more useful.

Re: [gentoo-dev] Re: Re: Re: [RFC] What features should be included in EAPI 2?

[Ciaran McCreesh]

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

On Thu, 21 Aug 2008 16:35:18 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Hmm fun as it isn't playing these games with you..

What? Deliberately arguing against an idea because it comes from the
wrong people, even though they're the only ones with the practical
experience on the issue?

> > Any reason you can provide for src_configure being useful can be
> > used with slight modification for src_prepare.
> >
> Which is no reason to add a new phase. OFC if zac wants to provide it
> that's entirely up to him.

Are you saying it is entirely up to him or that it should be entirely
up to him?

> >> Yeah I've always seen src_unpack as being more cogent to
> >> preparation of src files, than to actually untarring stuff.
> > 
> > Yes, the 'unpack' in the name really does go along with the phase
> > being used to prepare things.
> >
> Oh so this is about correct nomenclature rather than anything else? I
> see. 

It's about making the ebuild language fit what most ebuilds do.

> > Make a phase for each common logically distinct operation. Which,
> > with src_prepare being added, we almost have.
> >
> Yes, I see, because it's really needed; real functionality our users
> have been crying out for.

This one's a developer-targeted feature. The benefit to users is that
a) developers have a nicer package format to work with, and b) when
they want to add patches to an ebuild locally, they don't have to know
how to reimplement src_unpack correctly.

> > (The one missing is a src_fetch_extra or somesuch, for use by the
> > scm eclasses. But that wants special handling, and is probably best
> > left to another EAPI...)
> >
> Yes, a defined, configurable API for dealing with any version control
> would be useful, though your minion seemed to argue against it in
> #-portage. I can think of a couple of things that would be more
> useful to end-users: pkg_check for interactive ebuilds (eg license
> acceptance or media access), proper support for cross-compiling,
> integration of prefix, better handling of overlays, and of binpkgs..

And all of those are complicated features that can't be delivered with
ten minutes work, which would mean delaying EAPI 2.

> > Well, if you're proposing that Gentoo also adopts the more
> > complicated default_* functions from exheres-0, you're more than
> > welcome to write up a proposal...
> >
> Tsk of course not. default functions are in the pipeline in any case,
> but glad to see you're still using this list for proselytising your
> pet project while avoiding true discussion. 

You misunderstand, again. Exheres has two improvements on default
functions: the default_*/default mechanism, and better default_
implementations. Portage is taking only the former for EAPI 2.

> In any event, it wouldn't be needed.

Sure. You can do away with all the helpers and all the default
functions in a future EAPI if you want. But all that'd do is make
writing correct ebuilds much more tedious. Or, you can go the other
way, as Exheres has, and improve the current lot of defaults to make
writing ebuilds even easier.

> The reasoning others have given (yes it is possible to explain why
> without making people read thru 20 one line emails) is that this
> would be useful for live ebuilds.

Neither src_configure nor src_prepare makes much difference to live
ebuilds.

> Call the function what you like (or add a new phase with the hooks)
> it's still logically one point in time. For a live ebuild it's to
> prepare the src, for a normal one to (possibly) unpack and prepare.

Uhm. I think you're completely misunderstanding src_prepare. Go back
and read the original email. If that's not clear enough for you, also
have a look at how it's being used in Exherbo -- you can see plenty of
practical examples. Then, once you've done so, please explain how the
added simplicity and clarity is not a benefit.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: [RFC] What features should be included in EAPI 2?

[Thomas Anderson]

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

On Tue, Aug 19, 2008 at 11:31:17PM +0530, Arun Raghavan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ciaran McCreesh wrote:
> [...]
> > The benefit is that it's a logically separate action, and will avoid
> > all the silliness of people repeatedly changing their minds about
> > which phase should do the eautoreconf calls and so on.
> 
> a) Is this really an issue for maintainers?
As someone who has worked with exheres, I very much want this phase for
EAPI 2. It makes things simpler and more logical. Why should patching be
done in _unpack? It shouldn't, and that's a reason why _prepare should
be added.
> b) Does it really matter?
To me, yes

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

Re: [gentoo-dev] Re: Re: Re: [RFC] What features should be included in EAPI 2?

[Alec Warner]

On Thu, Aug 21, 2008 at 8:35 AM, Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Ciaran McCreesh wrote:
>
>> On Tue, 19 Aug 2008 21:27:03 +0100
>> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>>> > On Tue, 19 Aug 2008 23:31:17 +0530
>>> > Arun Raghavan <ford_prefect@gentoo.org> wrote:
>>> >> Ciaran McCreesh wrote:
>>> >> > The benefit is that it's a logically separate action, and will
>>> >> > avoid all the silliness of people repeatedly changing their
>>> >> > minds about which phase should do the eautoreconf calls and so
>>> >> > on.
>>> Er, that would be the new src_configure?
>>
>> Oh really?
>>
> Hmm fun as it isn't playing these games with you..
>

If he doesn't respond with anything useful; just act like he conceded
the point and move on.

>>> > In the grand scheme of things, no. In the grand scheme of things,
>>> > you only *need* a single src_ function. From a maintainer
>>> > convenience perspective, however, src_prepare is marginally more
>>> > useful than having a split src_configure.
>>> >
>>> How so?
>>>
>>> From a user point of view, and from a maintenance point of view,
>>> src_configure is very useful.
>>
>> Any reason you can provide for src_configure being useful can be used
>> with slight modification for src_prepare.
>>
> Which is no reason to add a new phase. OFC if zac wants to provide it that's
> entirely up to him.
>

You are saying src_configure is useful; he is saying src_prepare is
useful.  both of you are arguments as to why you think that way; that
is all he is saying.

>>> > It's a better mapping of the things ebuilds do than the current set
>>> > of functions.
>>> >
>>> > The logic is this: lots of ebuilds end up duplicating src_unpack
>>> > (or, in future EAPIs, calling 'default') and then adding things to
>>> > do preparation work. Experience suggests that the most common
>>> > reason for overriding src_unpack is to do preparation work, not to
>>> > change how things are unpacked.
>>> >
>>> Yeah I've always seen src_unpack as being more cogent to preparation
>>> of src files, than to actually untarring stuff.
>>
>> Yes, the 'unpack' in the name really does go along with the phase being
>> used to prepare things.
>>
> Oh so this is about correct nomenclature rather than anything else? I see.
>
>>> So what? Why make a new phase which every new dev has to know about,
>>> and we have to provide pre_ and post_ hooks for, when the existing
>>> phase covers the usage fine?
>>
>> Make a phase for each common logically distinct operation. Which, with
>> src_prepare being added, we almost have.
>>
> Yes, I see, because it's really needed; real functionality our users have
> been crying out for.
>

At least one has...do you want to vote for each feature?  What will it
take to convince you?

>> (The one missing is a src_fetch_extra or somesuch, for use by the scm
>> eclasses. But that wants special handling, and is probably best left to
>> another EAPI...)
>>
> Yes, a defined, configurable API for dealing with any version control would
> be useful, though your minion seemed to argue against it in #-portage. I
> can think of a couple of things that would be more useful to end-users:
> pkg_check for interactive ebuilds (eg license acceptance or media access),
> proper support for cross-compiling, integration of prefix, better handling
> of overlays, and of binpkgs..
>

Your comment is arguably about feature prioritization; not about
whether a given feature is necessary.

If we have two orthogonal features A and B; you can't argue that A is
necessary and B is not because A is more important to work on; the
only thing you have succeeded in doing is arguing that A should be
done first.

>>> > (Number-wise... For Exherbo, where the split's already been made,
>>> > custom src_prepare functions are three times more common than custom
>>> > src_unpack functions. And that figure's significantly lower than
>>> > what Gentoo would see, because with exheres-0 'default' functions
>>> > you don't need to write a src_prepare if you're merely applying
>>> > patches.)
>>> >
>>> Well it's easy enough to auto-apply patches, given a declaration in
>>> the ebuild (since files for all versions are in the same dir.) It
>>> certainly doesn't need a new phase.
>>
>> Well, if you're proposing that Gentoo also adopts the more complicated
>> default_* functions from exheres-0, you're more than welcome to write
>> up a proposal...
>>
> Tsk of course not. default functions are in the pipeline in any case, but
> glad to see you're still using this list for proselytising your pet project
> while avoiding true discussion. In any event, it wouldn't be needed.
>
>>> >> The *only* potential "benefit" I see here is that at some point of
>>> >> time in the nebulous future, it might be possible to tell the PM to
>>> >> always skip src_prepare in order to give a system where everything
>>> >> is "vanilla".
>>> >
>>> > Such a system wouldn't be usable... Not all of Gentoo's patches are
>>> > non-essential.
>>> >
>>> So the real, fully-defined, explicit benefit is..
>>
>> The same as the benefit of splitting src_compile into src_configure and
>> src_compile, except that it'll be of use to a slightly larger
>> proportion of ebuilds.
>>
> As ever, you fail to argue the actual case, preferring to hide behind "the
> same reasons as.." which is a variant on the "if you don't understand some
> one line comment, you're not qualified to discuss anything (plus you're
> ugly.)"
>
> The reasoning others have given (yes it is possible to explain why without
> making people read thru 20 one line emails) is that this would be useful
> for live ebuilds. In maintenance terms (when looking at the lifecycle of an
> ebuild) I don't see the need, since there is no unpacking required from a
> vcs pull. Once it's made into a normal ebuild, any preparation would
> necessarily require review and might not be needed at all.
>
> Call the function what you like (or add a new phase with the hooks) it's
> still logically one point in time. For a live ebuild it's to prepare the
> src, for a normal one to (possibly) unpack and prepare.
>
> src_configure is a logically distinct action which warrants a new phase,
> since the e*conf call in compile makes retrying a long build (without
> having to recompile stuff which doesn't need it) much more difficult; its
> absence prevents full use of make. Prepare does not warrant a new phase imo
> since it should only be run once per compilation instance; anything it does
> can either be done in unpack, or in configure should that be more useful.

src_prepare is a logically distinct action (maybe if we called it
src_patch it would be clearer?)
Certainly we only want to patch sources once every time we want to
build a package; what if patching is expensive?

The point being the same argument that is for src_configure (that it
is expensive and adding it makes ebuilds clearer) could be said for
src_prepare (preparation could be expensive and it makes ebuilds
clearer).

So why again should we not add it?

-Alec

[gentoo-dev] Re: Re: Re: Re: [RFC] What features should be included in EAPI 2?

[Steve Long]

Alec Warner wrote:

> At least one has...do you want to vote for each feature?  What will it
> take to convince you?
>
It's not up to me, and I've already conceded on IRC that the consensus is
against me (just letting others know); that's life *shrug*
 
>>> (The one missing is a src_fetch_extra or somesuch, for use by the scm
>>> eclasses. But that wants special handling, and is probably best left to
>>> another EAPI...)
>>>
>> Yes, a defined, configurable API for dealing with any version control
>> would be useful, though your minion seemed to argue against it in
>> #-portage. I can think of a couple of things that would be more useful to
>> end-users: pkg_check for interactive ebuilds (eg license acceptance or
>> media access), proper support for cross-compiling, integration of prefix,
>> better handling of overlays, and of binpkgs..
>>
> 
> Your comment is arguably about feature prioritization; not about
> whether a given feature is necessary.
> 
> If we have two orthogonal features A and B; you can't argue that A is
> necessary and B is not because A is more important to work on; the
> only thing you have succeeded in doing is arguing that A should be
> done first.
>
My point was that pkg_check has been requested from years ago, and focus (on
the ml, not in terms of what gets done on portage) over the last year or so
seems to be much more on things which make it easier for devs to work on
live ebuilds (not surprising with kde-4) not on stuff which would make the
end-user experience easier, which is what would bring more new users (and
thus new devs) in. Both are important, but making your users' lives easier
means less support burden, which means you get more time to play with shiny
new (aka 'broken') code.

Further, I think it would be cleaner if the package manager had a defined
configuration to deal with any version control system via an eclass,
meaning adding a new one would simply be a case of adding the .eclass to
the tree and the eclass name to a profile, with no changes at all required
in the mangler, beyond support for the base API (which is in any event
handled by bash.)

Eclass versioning would be nice too.

>> In maintenance terms (when looking at the
>> lifecycle of an ebuild) I don't see the need, since there is no unpacking
>> required from a vcs pull. Once it's made into a normal ebuild, any
>> preparation would necessarily require review and might not be needed at
>> all.
>>
>> Call the function what you like (or add a new phase with the hooks) it's
>> still logically one point in time. For a live ebuild it's to prepare the
>> src, for a normal one to (possibly) unpack and prepare.
>>
>> src_configure is a logically distinct action which warrants a new phase,
>> since the e*conf call in compile makes retrying a long build (without
>> having to recompile stuff which doesn't need it) much more difficult; its
>> absence prevents full use of make. Prepare does not warrant a new phase
>> imo since it should only be run once per compilation instance; anything
>> it does can either be done in unpack, or in configure should that be more
>> useful.
> 
> src_prepare is a logically distinct action (maybe if we called it
> src_patch it would be clearer?)
Er no you're fine, I've been thinking of it as src_patch for quite a while
now.

> Certainly we only want to patch sources once every time we want to
> build a package; what if patching is expensive?
>
Indeed, that was my point above; it only needs to be done once per instance,
whereas configure is something that might well be done more than once. How
does that change by having it in unpack (which is empty for a live vcs pull
in any case)?

Also, if you added support for declarative patches, I think you'd soon end
up in a similar situation as with unpack, where there simply isn't a need
for the ebuild author to write their own in the vast majority of cases.
Thing is you'd then be stuck with a new phase and unable to withdraw it,
cos it "only took 10 minutes to add."
 
> The point being the same argument that is for src_configure (that it
> is expensive and adding it makes ebuilds clearer) could be said for
> src_prepare (preparation could be expensive and it makes ebuilds
> clearer).
>
The compelling argument for configure isn't that it's clearer (although it
helps): it's that not having it makes it _impossible_ to restart an ebuild
which uses the standard configure make cycle, say if the user has turned
off collision-protect in order to get OpenOffice to install, or as recently
highlighted in #-dev-help, for an ebuild dev to do the same, via
FEATURES=noclean ebuild package.ebuild install.

Presumably that's the root cause of "confusion over where to put
eautoreconf," since putting it in unpack and not compile gets round the
issue.

> So why again should we not add it?
> 
I have no issue with the function being part of the EAPI; adding it as a
_phase_ seems less wise, but like I said, I accept the consensus is against
me.

Re: [gentoo-dev] [RFC] What features should be included in EAPI 2?

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.

Zac Medico wrote:
| Hello again,
|
| I'd like to get some feedback about what people would like to have
| in the final EAPI 2. In planning for this EAPI bump, we should
| strike a balance somewhere in between everything that we'd like to
| have and whatever we can implement in a short period of time. It
| doesn't really makes sense to delay the EAPI bump too much for
| implementation of new features, since those features can simply be
| reserved for a future EAPI bump.

Are there any other features that should be included in EAPI-2?
Does anyone have any objections to the features Zac listed?

| The latest experiment EAPI is 2_pre2, supported by
|> =sys-apps/portage-2.2_rc7. Please refer to the html documentation
| [1] for addition information about the experimental EAPI extensions
| which are summarized here:
|
|  * The 'doman' helper function recognizes language codes in man page
|    source files, and uses them to generate an appropriate
|    installation path.
|
|  * Dependency atoms can be constrained to match specific USE flag
|    states, including USE conditional expressions embedded within
|    the atoms themselves.
|
|  * The old src_compile phase function is split into separate
|    src_configure and src_compile fuctions.
|
|  * Default phase function implementations for the current EAPI are
|    accessible via a function having a name that begins with default_
|    and ends with the respective phase function name.
|
|  * Default phase function implementations for older EAPIs are
|    accessible via functions having names that start with 'eapi',
|    followed by the EAPI value.
|
|  * The default phase function implementation for the currently
|    executing phase is accessible as a function named 'default'.
|
| In addition to the above extensions, I've received a patch for
| SRC_URI arrows [2] that I plan to review but haven't had time yet.
| Please file bugs for any additional features that you'd like to add
| and mark them as blockers of bug 174380 [3].
|
| Thanks,
| Zac
|
| [1]
|
http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi
| [2] http://bugs.gentoo.org/show_bug.cgi?id=177863
| [3] http://bugs.gentoo.org/show_bug.cgi?id=174380

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkizD/sACgkQcAWygvVEyAKb6ACfd3ODwtS0LzGyblGdvsfnXCkn
xuMAn0FwJV6C0sTY5uFYp/OmSLmbrihb
=kWTD
-----END PGP SIGNATURE-----

[gentoo-dev] Re: [RFC] What features should be included in EAPI 2?

[Ryan Hill]

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

On Tue, 19 Aug 2008 21:27:03 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:

> Ciaran McCreesh wrote:

> >> b) Does it really matter?
> > 
> > In the grand scheme of things, no. In the grand scheme of things,
> > you only *need* a single src_ function. From a maintainer
> > convenience perspective, however, src_prepare is marginally more
> > useful than having a split src_configure.
> >
> How so?
> 
> From a user point of view, and from a maintenance point of view,
> src_configure is very useful.

As a maintainer I would find it very useful to be able to do `ebuild
foo-1.ebuild <phase>` to get the build dir into following states:

a)  pristine source (unpack)
b)  patched, seded, eautoreconf'd, or
everything-else-we're-doing-in-src_unpack-right-now'd (prepare)
c)  ./configured (configure)
d)  compiled (compile)

the state between a) and b) is very useful as anyone who has
gone back and forth commenting and uncommenting epatch/eautoreconf lines
in src_unpack (ie. everyone) can attest.  between c) and d) would be
less useful for me but still quite welcome.


-- 
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: Re: Re: [RFC] What features should be included in EAPI 2?

[Peter Volkov]

В Чтв, 21/08/2008 в 19:26 -0700, Alec Warner пишет:
> src_prepare is a logically distinct action (maybe if we called it
> src_patch it would be clearer?)

We are not only patching sources there but modify them by other means
too (like sed or find .. rm \{\};). So src_prepare is the name which
better reflects intention.

В Втр, 19/08/2008 в 12:12 +0100, Steve Long пишет:
> Besides saving one line of typing, what is the benefit of adding this
> new phase?

Although this disagreement is already closed I'd like to point that
sometimes it's more than one line:

http://overlays.gentoo.org/dev/pva/browser/x11-apps/gxneur/gxneur-0.9.0_p106.ebuild

Also... well Ryan already made the point I was going to write. :)

-- 
Peter.