[gentoo-pms] EAPI 5 development branch

[gentoo-pms] EAPI 5 development branch

[Ciaran McCreesh]

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

I've pushed an eapi-5 branch for development work. Feel free to screw
around with it. It's probably best to assume that we might rebase /
rewrite / do naughty things on it, and that we'll cherry pick to master
and throw it away when we're done.

So far:

* Add \ChangeWhenAddingAnEAPI command.
* Add an EAPI 5 identical to EAPI 4
* EAPI 5 has econf --disable-silent-rules
* Slot operator dependencies are back in EAPI 5
* Profile IUSE injection is in EAPI 5.
* IMAGE is removed in EAPI 5.
* EAPI 5 supports ?? ( ) groups
* EAPI 5 has apply_user_patches
* EAPI 5 has EBUILD_PHASE_FUNC
* Split up big table into two littler tables.
* EAPI 5 mandates GNU find

Not done:

* EAPI parsing text
* Licence groups
* usex
* has/best_version root
* EJOBS
* doheader
* stdin / new* / here*

Things I'm conveniently ignoring because I don't like them or because
I forgot:

* Everything else

-- 
Ciaran McCreesh

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

[gentoo-pms] apply_user_patches (was: EAPI 5 development branch)

[Ulrich Mueller]

| Furthermore, for these EAPIs, if the function is overridden, it
| shall be a fatal error if the apply_user_patches command has not
| been called at least once by the end of the phase.

Wouldn't it make more sense to call apply_user_patches implicitly at
the end of the phase, if it hasn't been called before?

Otherwise, a call to that function would have to be added to every
ebuild that defines src_prepare.

Ulrich

Re: [gentoo-pms] apply_user_patches (was: EAPI 5 development branch)

[Ciaran McCreesh]

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

On Mon, 7 May 2012 02:12:14 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> | Furthermore, for these EAPIs, if the function is overridden, it
> | shall be a fatal error if the apply_user_patches command has not
> | been called at least once by the end of the phase.
> 
> Wouldn't it make more sense to call apply_user_patches implicitly at
> the end of the phase, if it hasn't been called before?
> 
> Otherwise, a call to that function would have to be added to every
> ebuild that defines src_prepare.

That was the point. The discussion on gentoo-dev suggested that "at the
end" is often the wrong place to put it, due to eautoreconf etc. We
need people to be explicit about where it goes.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] apply_user_patches (was: EAPI 5 development branch)

[Ulrich Mueller]

>>>>> On Mon, 7 May 2012, Ciaran McCreesh wrote:

> On Mon, 7 May 2012 02:12:14 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
>> | Furthermore, for these EAPIs, if the function is overridden, it
>> | shall be a fatal error if the apply_user_patches command has not
>> | been called at least once by the end of the phase.
>> 
>> Wouldn't it make more sense to call apply_user_patches implicitly at
>> the end of the phase, if it hasn't been called before?
>> 
>> Otherwise, a call to that function would have to be added to every
>> ebuild that defines src_prepare.

> That was the point. The discussion on gentoo-dev suggested that "at
> the end" is often the wrong place to put it, due to eautoreconf etc.
> We need people to be explicit about where it goes.

Yes, so apply_user_patches gives ebuilds the possibility to specify
the exact place. I still think that a fallback to calling it at the
end of the phase would be better than aborting with a fatal error.

After all, this functionality is just a stop-gap measure for users to
apply quick bug fixes, so I don't expect that it will be used very
often. Even fewer cases will require that eautoreconf is called. Do we
really want to force developers to put this function call into every
ebuild? That would be out of proportion, IMHO.

Ulrich

Re: [gentoo-pms] apply_user_patches

[Michael Orlitzky]

On 05/07/12 11:17, Ulrich Mueller wrote:
> 
> After all, this functionality is just a stop-gap measure for users to
> apply quick bug fixes, so I don't expect that it will be used very
> often. Even fewer cases will require that eautoreconf is called. Do we
> really want to force developers to put this function call into every
> ebuild? That would be out of proportion, IMHO.

Only the ebuilds that override src_prepare (which is a lot).

The argument on -dev was that we could get 80% of the benefit for 0% of
the effort by just ignoring the issue. There's a trade-off, but 80%
isn't all that great (considering of course that all of these numbers
are made up).

Can that be increased to, say, 99% without any extra effort?

Are there easy heuristics to determine whether or not user patches
require eautoreconf? For example, if the patches fail at the beginning
of src_prepare, and the ebuild calls eautoreconf, that's a good
indication that we should call eautoreconf after the user patches are
applied (at the end of src_prepare).

Lacking a better way, though, I think requiring the developer to apply
the patches in the right spot is the only way to ensure correctness.

Re: [gentoo-pms] apply_user_patches

[Michał Górny]

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

On Mon, 07 May 2012 12:19:40 -0400
Michael Orlitzky <michael@orlitzky.com> wrote:

> On 05/07/12 11:17, Ulrich Mueller wrote:
> > 
> > After all, this functionality is just a stop-gap measure for users
> > to apply quick bug fixes, so I don't expect that it will be used
> > very often. Even fewer cases will require that eautoreconf is
> > called. Do we really want to force developers to put this function
> > call into every ebuild? That would be out of proportion, IMHO.
> 
> Only the ebuilds that override src_prepare (which is a lot).

The reason for src_prepare() was to simplify ebuilds (so they don't
have to override whole src_unpack()). Requiring a specific line in
every src_prepare() call means going the other way.

> Can that be increased to, say, 99% without any extra effort?
> 
> Are there easy heuristics to determine whether or not user patches
> require eautoreconf? For example, if the patches fail at the beginning
> of src_prepare, and the ebuild calls eautoreconf, that's a good
> indication that we should call eautoreconf after the user patches are
> applied (at the end of src_prepare).

That's an extra effort. And by making it overcomplex, you introduce yet
another new corner cases.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-pms] apply_user_patches

[Ciaran McCreesh]

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

On Mon, 7 May 2012 18:41:30 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Mon, 07 May 2012 12:19:40 -0400
> Michael Orlitzky <michael@orlitzky.com> wrote:
> > On 05/07/12 11:17, Ulrich Mueller wrote:
> > > 
> > > After all, this functionality is just a stop-gap measure for users
> > > to apply quick bug fixes, so I don't expect that it will be used
> > > very often. Even fewer cases will require that eautoreconf is
> > > called. Do we really want to force developers to put this function
> > > call into every ebuild? That would be out of proportion, IMHO.
> > 
> > Only the ebuilds that override src_prepare (which is a lot).
> 
> The reason for src_prepare() was to simplify ebuilds (so they don't
> have to override whole src_unpack()). Requiring a specific line in
> every src_prepare() call means going the other way.

The goal is not simplicity. The goal is the simplest solution that
works. Catching problems early on is a huge advantage.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] apply_user_patches

[Ulrich Mueller]

>>>>> On Mon, 7 May 2012, Michał Górny wrote:

> On Mon, 07 May 2012 12:19:40 -0400
> Michael Orlitzky <michael@orlitzky.com> wrote:

>> > After all, this functionality is just a stop-gap measure for users
>> > to apply quick bug fixes, so I don't expect that it will be used
>> > very often. Even fewer cases will require that eautoreconf is
>> > called. Do we really want to force developers to put this function
>> > call into every ebuild? That would be out of proportion, IMHO.
>> 
>> Only the ebuilds that override src_prepare (which is a lot).

> The reason for src_prepare() was to simplify ebuilds (so they don't
> have to override whole src_unpack()). Requiring a specific line in
> every src_prepare() call means going the other way.

+1

Also, if we add the feature to EAPI 5, we won't get anything close to
100% coverage for a very long time. (Looking at usage statistics, EAPI
2 was introduced almost 4 years ago, and about 30% of the tree are
still at EAPI 0 or 1.)

Couldn't the PM call a user-supplied script (which would be a file
with a special name placed in the same directory) after applying the
user patches? Since this script could do any postprocessing required,
applying user patches could be postponed until after src_prepare.

Ulrich

Re: [gentoo-pms] apply_user_patches

[Ciaran McCreesh]

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

On Mon, 7 May 2012 20:16:30 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> Also, if we add the feature to EAPI 5, we won't get anything close to
> 100% coverage for a very long time. (Looking at usage statistics, EAPI
> 2 was introduced almost 4 years ago, and about 30% of the tree are
> still at EAPI 0 or 1.)

Doesn't matter. The point is to offer a feature which won't fail
unexpectedly. If a user tries to supply patches for an ebuild that
doesn't explicitly support it, the user gets told at pretend time.

> Couldn't the PM call a user-supplied script (which would be a file
> with a special name placed in the same directory) after applying the
> user patches? Since this script could do any postprocessing required,
> applying user patches could be postponed until after src_prepare.

If you want to do it that way, the feature should have no EAPI or tree
support at all, and it becomes entirely reliant upon users knowing
enough to sort out the problems themselves.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] apply_user_patches (was: EAPI 5 development branch)

[Ciaran McCreesh]

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

On Mon, 7 May 2012 17:17:10 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Mon, 7 May 2012, Ciaran McCreesh wrote:
> > On Mon, 7 May 2012 02:12:14 +0200
> > Ulrich Mueller <ulm@gentoo.org> wrote:
> >> | Furthermore, for these EAPIs, if the function is overridden, it
> >> | shall be a fatal error if the apply_user_patches command has not
> >> | been called at least once by the end of the phase.
> >> 
> >> Wouldn't it make more sense to call apply_user_patches implicitly
> >> at the end of the phase, if it hasn't been called before?
> >> 
> >> Otherwise, a call to that function would have to be added to every
> >> ebuild that defines src_prepare.
> 
> > That was the point. The discussion on gentoo-dev suggested that "at
> > the end" is often the wrong place to put it, due to eautoreconf etc.
> > We need people to be explicit about where it goes.
> 
> Yes, so apply_user_patches gives ebuilds the possibility to specify
> the exact place. I still think that a fallback to calling it at the
> end of the phase would be better than aborting with a fatal error.

Why? That error will only happen at most once, and users will never
see it.

> After all, this functionality is just a stop-gap measure for users to
> apply quick bug fixes, so I don't expect that it will be used very
> often. Even fewer cases will require that eautoreconf is called. Do we
> really want to force developers to put this function call into every
> ebuild? That would be out of proportion, IMHO.

"It not being used very often" is the key issue: developers are likely
to forget about it if they're not forced to remember. It's especially
complicated when eclasses are involved, so even if developers do
remember, they may not be sure whether they have to specify it in a
particular case.

We can avoid a huge pile of "blah doesn't work properly with user
patches!" bugs here, essentially for free.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] EAPI 5 development branch

[Ulrich Mueller]

>>>>> On Sun, 6 May 2012, Ciaran McCreesh wrote:

> I've pushed an eapi-5 branch for development work. Feel free to screw
> around with it. It's probably best to assume that we might rebase /
> rewrite / do naughty things on it, and that we'll cherry pick to master
> and throw it away when we're done.

> So far:

> * Add \ChangeWhenAddingAnEAPI command.
> * Add an EAPI 5 identical to EAPI 4
> * EAPI 5 has econf --disable-silent-rules
> * Slot operator dependencies are back in EAPI 5
> * Profile IUSE injection is in EAPI 5.
> * IMAGE is removed in EAPI 5.
> * EAPI 5 supports ?? ( ) groups
> * EAPI 5 has apply_user_patches
> * EAPI 5 has EBUILD_PHASE_FUNC
> * Split up big table into two littler tables.
> * EAPI 5 mandates GNU find

> Not done:

> * EAPI parsing text

Merged from master, and changed from optional to mandatory parsing.

> * stdin / new* / here*

Done.

> * Licence groups
> * usex
> * has/best_version root
> * EJOBS
> * doheader

These are still missing.

> Things I'm conveniently ignoring because I don't like them or
> because I forgot:

> * Everything else

Any particular reason for leaving out "No -j1 for src_test"? It was on
your previous list.

Ulrich

Re: [gentoo-pms] EAPI 5 development branch

[Ciaran McCreesh]

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

On Thu, 10 May 2012 11:04:12 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> > * stdin / new* / here*
> 
> Done.

The way you've worded it sort of looks like it only applies to newbin
(although the same could be said for some of the existing wording).
Maybe we should restructure that big list into "do" commands, "new"
commands and "permissions" commands, so we can put a paragraph for each
feature group?

> Any particular reason for leaving out "No -j1 for src_test"? It was on
> your previous list.

I couldn't find -j1 being mandated in the spec, and Portage doesn't
seem to do it any more.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] EAPI 5 development branch

[Ulrich Mueller]

>>>>> On Thu, 10 May 2012, Ciaran McCreesh wrote:

> On Thu, 10 May 2012 11:04:12 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
>> > * stdin / new* / here*
>> 
>> Done.

> The way you've worded it sort of looks like it only applies to
> newbin (although the same could be said for some of the existing
> wording). Maybe we should restructure that big list into "do"
> commands, "new" commands and "permissions" commands, so we can put a
> paragraph for each feature group?

Please go ahead. Should this be done in master, too?

There's also "keepdir" which isn't covered by any of the above.

Ulrich

Re: [gentoo-pms] EAPI 5 development branch

[Zac Medico]

On 05/10/2012 02:19 AM, Ciaran McCreesh wrote:
> On Thu, 10 May 2012 11:04:12 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
>> Any particular reason for leaving out "No -j1 for src_test"? It was on
>> your previous list.
> 
> I couldn't find -j1 being mandated in the spec, and Portage doesn't
> seem to do it any more.

Portage still does it (_eapi0_src_test function inside
bin/phase-helpers.sh). If the -j1 isn't mandated then I'll just go ahead
and remove it.
-- 
Thanks,
Zac

Re: [gentoo-pms] EAPI 5 development branch

[Ulrich Mueller]

>>>>> On Thu, 10 May 2012, Zac Medico wrote:

>>> Any particular reason for leaving out "No -j1 for src_test"? It was on
>>> your previous list.
>> 
>> I couldn't find -j1 being mandated in the spec, and Portage doesn't
>> seem to do it any more.

> Portage still does it (_eapi0_src_test function inside
> bin/phase-helpers.sh). If the -j1 isn't mandated then I'll just go
> ahead and remove it.

In fact, the spec says:
| The default implementation used when the ebuild lacks the src_test
| function must, if tests are enabled, run make check if and only if
| such a target is available, or if not run make test, if and only
| such a target is available.

I guess "make check" implies that no -j option is passed to make,
which is equivalent to -j1.

Ulrich

Re: [gentoo-pms] EAPI 5 development branch

[Ciaran McCreesh]

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

On Thu, 10 May 2012 07:19:45 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> On 05/10/2012 02:19 AM, Ciaran McCreesh wrote:
> > On Thu, 10 May 2012 11:04:12 +0200
> > Ulrich Mueller <ulm@gentoo.org> wrote:
> >> Any particular reason for leaving out "No -j1 for src_test"? It
> >> was on your previous list.
> > 
> > I couldn't find -j1 being mandated in the spec, and Portage doesn't
> > seem to do it any more.
> 
> Portage still does it (_eapi0_src_test function inside
> bin/phase-helpers.sh). If the -j1 isn't mandated then I'll just go
> ahead and remove it.

Oh, I missed that. In that case we should probably specifically say -j1
for older EAPIs, and not for EAPI 5. From Exherbo's experience, some
packages do break without the -j1, but not very many. IIRC the -j1 got
in there originally because two of those packages used to be perl and
vim, which were two of the things we looked at when creating src_test.

-- 
Ciaran McCreesh

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