[gentoo-project] EAPI6 Features

[gentoo-project] EAPI6 Features

[Rich Freeman]

Most of the proposed EAPI6 features seem ripe for acceptance, but I
figured I'd comment on a few here in case others want to weigh in.

On Thu, May 29, 2014 at 9:56 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>
>    b) failglob in global scope
>         Bug #463822 [13]

I'm a bit concerned that this one could be a cure worse than the
disease - unintended side-effects/etc.  A repoman check seems a lot
less likely to cause problems.

Part of me wonders that there is a trend towards using bash as a
general-purpose programming language.  Just about any higher-level
data/control/etc structure in bash tends to be cumbersome.  Really all
the non-fatal die stuff is nothing more than exception handling in a
language not designed for exception handling, but that at least seems
manageable.

>
> 4. Features rejected from EAPI 5

Ok, I suspect we're going to spend about 95% of the time on these.
Few have much progress since the last time they were rejected.

>
>    a) Patch applying function in package manager
>         Bug #463768 [14]
>         - Needed for 2d) and 4b)
>         - This will duplicate epatch() from eutils, in simplified form.
>         - Name "eapply" has been suggested.
>

My two cents.  Keep an eclass for the fancy stuff, but move into the
EAPI a few basic patch functions:

1.  Application of a patch file, defaulting to -p1, allowing override
of -p level, but without auto-detection.
2.  Application of a directory full of patch files in lexical order,
again supporting override of -p level without auto-detection.

I'm not a big fan of either auto-detection or forcing patch re-writes
to be -p1 always.

>    b) User patches
>         Bug #475288 [15], PMS wording [16]
>         - Needs 4a)
>         - Current wording of the spec requires that every ebuild must
>           include a call to the function in src_prepare, which is
>           controversial.
>         - Names "apply_user_patches" or "eapply_user" have been suggested.
>

I'm generally fine with it (we can bikeshed the name to death later),
but is there any reason to not just simply apply the patches after
src_prepare is done and not make maintainers call it?  If we're
concerned about sequencing with other activities in src_prepare then
that is fine - I don't have a big problem with it being a fatal error
if it doesn't get called.

>    c) EJOBS variable
>         Bug #273101 [17], gentoo-dev discussion [18]
>         - Discussion was in 2008. Is there (still) consensus?
>

Assuming anybody still wants to implement this, I see no reason to
keep bikeshedding this.  EJOBS fits the bill.

The only thing that might be worth noting is that distcc users may
have an interest in distinguishing between gcc jobs and everything
else.  I once messed with dictcc with very high job numbers and it
worked great when make hit a directory full of .c files, and not so
great when make/ant/whatever tried to run 50 instances of java in
parallel.

>    d) Source eclasses only once
>         Bug #422533 [19], gentoo-dev discussion [20]
>

Does anybody still want this included?  It seems to me like the list
discussion was leading in a different direction, but it isn't 100%
clear to me if this is the case.


>    e) HDEPEND: host dependencies for cross-compilation
>         Bug #317337 [21]
>

It isn't 100% clear to me which of the 14 proposed solutions in that
bug is the final answer, but I think it is DEPEND becomes target
depends, and HDEPEND is introduced as host depends.

Is the final intent that if HDEPEND isn't defined, then
HDEPEND=DEPEND, or does HDEPEND=""?

The ones I didn't mention seem basically fine as-is, or with the
tweaks already mentioned in the bugs.

Rich

Re: [gentoo-project] EAPI6 Features

[Ulrich Mueller]

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

>>>>> On Sun, 8 Jun 2014, Rich Freeman wrote:

>> b) failglob in global scope
>> Bug #463822

> I'm a bit concerned that this one could be a cure worse than the
> disease - unintended side-effects/etc.  A repoman check seems a lot
> less likely to cause problems.

Any specific example of a side effect that you have in mind? I believe
that there are none in global scope, but maybe we shouldn't extend the
feature to function scope.

>> 4. Features rejected from EAPI 5

> Ok, I suspect we're going to spend about 95% of the time on these.

Yes. ;-)

>> a) Patch applying function in package manager
>> Bug #463768
>> - Needed for 2d) and 4b)
>> - This will duplicate epatch() from eutils, in simplified form.
>> - Name "eapply" has been suggested.

> My two cents.  Keep an eclass for the fancy stuff, but move into the
> EAPI a few basic patch functions:

> 1.  Application of a patch file, defaulting to -p1, allowing override
> of -p level, but without auto-detection.
> 2.  Application of a directory full of patch files in lexical order,
> again supporting override of -p level without auto-detection.

> I'm not a big fan of either auto-detection or forcing patch re-writes
> to be -p1 always.

This more or less agrees with the status of the discussion:
https://bugs.gentoo.org/show_bug.cgi?id=463768#c32

We haven't decided yet if there should be autodetection, but I'd also
prefer a -p1 default without autodetection. There's always epatch if
you need anything more fancy.

>> b) User patches
>> Bug #475288
>> - Needs 4a)
>> - Current wording of the spec requires that every ebuild must
>> include a call to the function in src_prepare, which is
>> controversial.
>> - Names "apply_user_patches" or "eapply_user" have been suggested.

> I'm generally fine with it (we can bikeshed the name to death later),
> but is there any reason to not just simply apply the patches after
> src_prepare is done and not make maintainers call it?  If we're
> concerned about sequencing with other activities in src_prepare then
> that is fine - I don't have a big problem with it being a fatal error
> if it doesn't get called.

IMHO the package manager shouldn't perform any operations between
src_* phases, outside of phase functions. Therefore, the user patch
function should be called either from src_prepare, or from a phase
function (src_userpatch?) newly introduced.

I'd strongly dislike a new phase function, but conceptionally, it
would still be much cleaner than doing some magic after src_prepare.

My suggestion would be to add the user patch function to
default_src_prepare, plus a policy that the function must be called if
an ebuild (or eclass) contains an explicit src_prepare(). The latter
could be enforced by repoman.

>> c) EJOBS variable
>> Bug #273101
>> - Discussion was in 2008. Is there (still) consensus?

> Assuming anybody still wants to implement this, I see no reason to
> keep bikeshedding this.  EJOBS fits the bill.

> The only thing that might be worth noting is that distcc users may
> have an interest in distinguishing between gcc jobs and everything
> else.  I once messed with dictcc with very high job numbers and it
> worked great when make hit a directory full of .c files, and not so
> great when make/ant/whatever tried to run 50 instances of java in
> parallel.

I don't have a strong opinion about this one.

However, my general advice would be not to impose work on PMS and
package manager teams, for features that nobody is pushing any longer.

>> d) Source eclasses only once
>> Bug #422533

> Does anybody still want this included?  It seems to me like the list
> discussion was leading in a different direction, but it isn't 100%
> clear to me if this is the case.

Right, discussion has died down. Many eclasses now use a mechanism
equivalent to the one in C header files, which seems to do the job.

>> e) HDEPEND: host dependencies for cross-compilation
>> Bug #317337

> It isn't 100% clear to me which of the 14 proposed solutions in that
> bug is the final answer, but I think it is DEPEND becomes target
> depends, and HDEPEND is introduced as host depends.

> Is the final intent that if HDEPEND isn't defined, then
> HDEPEND=DEPEND, or does HDEPEND=""?

We did RDEPEND=${DEPEND} once and it was a mistake. So I think default
HDEPEND should be empty.

Ulrich

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

Re: [gentoo-project] EAPI6 Features

[Rich Freeman]

On Sun, Jun 8, 2014 at 10:38 AM, Ulrich Mueller <ulm@gentoo.org> wrote:

Lots of other good stuff that I agree with across the board...

>>>>>> On Sun, 8 Jun 2014, Rich Freeman wrote:
>>> c) EJOBS variable
>>> Bug #273101
>>> - Discussion was in 2008. Is there (still) consensus?
>
>> Assuming anybody still wants to implement this, I see no reason to
>> keep bikeshedding this.  EJOBS fits the bill.
>
> However, my general advice would be not to impose work on PMS and
> package manager teams, for features that nobody is pushing any longer.

As I already said - agreed across the board.  With regard to EJOBS in
particular I'd like the community to speak up if somebody actually
wants this.  Preferably that would be somebody willing to pitch in and
help a bit when it comes time to implement it, but I'll take all the
sponsors I can get.

Rich

Re: [gentoo-project] EAPI6 Features

[Pacho Ramos]

El dom, 08-06-2014 a las 16:38 +0200, Ulrich Mueller escribió:
[...]
> >> d) Source eclasses only once
> >> Bug #422533
> 
> > Does anybody still want this included?  It seems to me like the list
> > discussion was leading in a different direction, but it isn't 100%
> > clear to me if this is the case.
> 
> Right, discussion has died down. Many eclasses now use a mechanism
> equivalent to the one in C header files, which seems to do the job.
> 

Last time I checked, there were still some eclasses not doing that
(either the "spank" way or the way from python -r1 eclasses). Not sure
if this was intended and why that eclasses are pending :/ If there is no
technical issue in fixing them (probably with the way used in python
eclasses ;)), why not simply go ahead and fix them? (not sure how could
we check for this issue in future eclasses that could be added without
this tricks included)

Re: [gentoo-project] EAPI6 Features

[Ulrich Mueller]

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

>>>>> On Sun, 08 Jun 2014, Pacho Ramos wrote:

> El dom, 08-06-2014 a las 16:38 +0200, Ulrich Mueller escribió:
>> Many eclasses now use a mechanism equivalent to the one in C header
>> files, which seems to do the job.

> Last time I checked, there were still some eclasses not doing that
> (either the "spank" way or the way from python -r1 eclasses). Not
> sure if this was intended and why that eclasses are pending :/ If
> there is no technical issue in fixing them (probably with the way
> used in python eclasses ;)), why not simply go ahead and fix them?

The feature is strictly needed only for eclasses that are inherited
by another eclass. (If we would distinguish between eclasses and
"eclass libraries" then it would be clearer where it is needed and
where it is not.)

Ulrich

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

Re: [gentoo-project] EAPI6 Features

[Pacho Ramos]

El dom, 08-06-2014 a las 22:56 +0200, Ulrich Mueller escribió:
> >>>>> On Sun, 08 Jun 2014, Pacho Ramos wrote:
> 
> > El dom, 08-06-2014 a las 16:38 +0200, Ulrich Mueller escribió:
> >> Many eclasses now use a mechanism equivalent to the one in C header
> >> files, which seems to do the job.
> 
> > Last time I checked, there were still some eclasses not doing that
> > (either the "spank" way or the way from python -r1 eclasses). Not
> > sure if this was intended and why that eclasses are pending :/ If
> > there is no technical issue in fixing them (probably with the way
> > used in python eclasses ;)), why not simply go ahead and fix them?
> 
> The feature is strictly needed only for eclasses that are inherited
> by another eclass. (If we would distinguish between eclasses and
> "eclass libraries" then it would be clearer where it is needed and
> where it is not.)
> 
> Ulrich

And, what problems could cause to include it for all eclasses? Maybe
some eclass is not currently inherited by other eclass but could be in
the future

Re: [gentoo-project] EAPI6 Features

[Michał Górny]

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

Dnia 2014-06-08, o godz. 16:38:43
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >> d) Source eclasses only once
> >> Bug #422533  
> 
> > Does anybody still want this included?  It seems to me like the list
> > discussion was leading in a different direction, but it isn't 100%
> > clear to me if this is the case.  
> 
> Right, discussion has died down. Many eclasses now use a mechanism
> equivalent to the one in C header files, which seems to do the job.

I specifically did open that bug because eclasses were not using
the same way consistently. More specifically, the 'spank way' usually
involved EXPORT_FUNCTIONS being used inconsistently. As a result,
sometimes phase functions from eclass inherited last weren't actually
effective because the eclass was inherited by another eclass earlier.

Thinking about it right now, I don't think we need anything
EAPI-specific for this. A consistent policy that is respected by all
developers would be enough. I would prefer 'my way' here, that is
guarding all inherits and eclass code except for EXPORT_FUNCTIONS, so
that the repetitive inherit still overrides phase functions.

That is:

  if [[ ! ${_FOO_ECLASS} ]]; then
    inherit bar baz
  fi

  EXPORT_FUNCTIONS src_compile src_install

  if [[ ! ${_FOO_ECLASS} ]]; then
    #...

    _FOO_ECLASS=1
  fi

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] EAPI6 Features

[Jeroen Roovers]

On Sun, 8 Jun 2014 09:04:20 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> >    c) EJOBS variable
> >         Bug #273101 [17], gentoo-dev discussion [18]
> >         - Discussion was in 2008. Is there (still) consensus?

> The only thing that might be worth noting is that distcc users may
> have an interest in distinguishing between gcc jobs and everything
> else.  I once messed with dictcc with very high job numbers and it
> worked great when make hit a directory full of .c files, and not so
> great when make/ant/whatever tried to run 50 instances of java in
> parallel.

Not just distcc! We already regularly see problems with a combination of
(a) tons of RAM, (b) a dozen CPUs and (b) matching MAKEOPTS and (d)
-pipe, where concurrent linker jobs surprisingly consume all of the
RAM and one or more linker jobs segfault or get killed. Anyone's
MAKEOPTS calculation should already include all of those factors.


Regards,
     jer

Re: [gentoo-project] EAPI6 Features

[Ulrich Mueller]

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

>>>>> On Sun, 8 Jun 2014, Jeroen Roovers wrote:

> On Sun, 8 Jun 2014 09:04:20 -0400
> Rich Freeman <rich0@gentoo.org> wrote:

>> >    c) EJOBS variable
>> >         Bug #273101 [17], gentoo-dev discussion [18]
>> >         - Discussion was in 2008. Is there (still) consensus?

>> The only thing that might be worth noting is that distcc users may
>> have an interest in distinguishing between gcc jobs and everything
>> else.  I once messed with dictcc with very high job numbers and it
>> worked great when make hit a directory full of .c files, and not so
>> great when make/ant/whatever tried to run 50 instances of java in
>> parallel.

> Not just distcc! We already regularly see problems with a
> combination of (a) tons of RAM, (b) a dozen CPUs and (b) matching
> MAKEOPTS and (d) -pipe, where concurrent linker jobs surprisingly
> consume all of the RAM and one or more linker jobs segfault or get
> killed. Anyone's MAKEOPTS calculation should already include all of
> those factors.

Also, extraction of jobs and load average from MAKEOPTS isn't so
complicated. In fact, multiprocessing.eclass already provides
functions makeopts_jobs() and makeopts_loadavg() for this purpose.

Ulrich

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

Re: [gentoo-project] EAPI6 Features

[Andreas K. Huettel]

Am Sonntag, 8. Juni 2014, 15:04:20 schrieb Rich Freeman:
> Most of the proposed EAPI6 features seem ripe for acceptance, but I
> figured I'd comment on a few here in case others want to weigh in.
> 

We should probably revisit IUSE_RUNTIME. 
https://archives.gentoo.org/gentoo-dev/msg_8b664f7fab584b23dbb10d10e3a0a7e5.xml

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-project] EAPI6 Features

[Ciaran McCreesh]

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

On Sun, 8 Jun 2014 19:22:09 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
> Am Sonntag, 8. Juni 2014, 15:04:20 schrieb Rich Freeman:
> > Most of the proposed EAPI6 features seem ripe for acceptance, but I
> > figured I'd comment on a few here in case others want to weigh in.
> 
> We should probably revisit IUSE_RUNTIME. 
> https://archives.gentoo.org/gentoo-dev/msg_8b664f7fab584b23dbb10d10e3a0a7e5.xml

Has anyone implemented it and tried it out in practice?

-- 
Ciaran McCreesh

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

Re: [gentoo-project] EAPI6 Features

[Ulrich Mueller]

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

>>>>> On Sun, 8 Jun 2014, Andreas K Huettel wrote:

> We should probably revisit IUSE_RUNTIME. 
> https://archives.gentoo.org/gentoo-dev/msg_8b664f7fab584b23dbb10d10e3a0a7e5.xml

IIUC this is GLEP 62, which is separate from EAPI 6.

Ulrich

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

Re: [gentoo-project] EAPI6 Features

[Michał Górny]

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

Dnia 2014-06-08, o godz. 19:28:45
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Sun, 8 Jun 2014, Andreas K Huettel wrote:  
> 
> > We should probably revisit IUSE_RUNTIME. 
> > https://archives.gentoo.org/gentoo-dev/msg_8b664f7fab584b23dbb10d10e3a0a7e5.xml  
> 
> IIUC this is GLEP 62, which is separate from EAPI 6.

The original proposal aimed for adding it as optional, EAPI-independent
feature -- and that was GLEP 62. However, we decided that instead we'd
like to add it along with a new EAPI.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] EAPI6 Features

[Rich Freeman]

On Sun, Jun 8, 2014 at 5:40 PM, Michał Górny <mgorny@gentoo.org> wrote:
>
> The original proposal aimed for adding it as optional, EAPI-independent
> feature -- and that was GLEP 62. However, we decided that instead we'd
> like to add it along with a new EAPI.
>

That makes sense.  We have a well-defined mechanism for introducing
features to ebuilds, so why do something out-of-band.  We could of
course do another EAPI bump just for this later, but I wouldn't just
slip it retroactively into an existing EAPI.

Is this proposal ready for prime time yet?  We could defer voting on
it Tues and slip it in before the EAPI is finalized, but I know the
PMS team would like to do a feature freeze hence the agenda item.

Rich

Re: [gentoo-project] EAPI6 Features

[Michał Górny]

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

Dnia 2014-06-08, o godz. 18:58:01
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Sun, Jun 8, 2014 at 5:40 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > The original proposal aimed for adding it as optional, EAPI-independent
> > feature -- and that was GLEP 62. However, we decided that instead we'd
> > like to add it along with a new EAPI.
> 
> That makes sense.  We have a well-defined mechanism for introducing
> features to ebuilds, so why do something out-of-band.  We could of
> course do another EAPI bump just for this later, but I wouldn't just
> slip it retroactively into an existing EAPI.
> 
> Is this proposal ready for prime time yet?  We could defer voting on
> it Tues and slip it in before the EAPI is finalized, but I know the
> PMS team would like to do a feature freeze hence the agenda item.

Well, I don't think it's going to change much. It may suffer cosmetic
changes but it's mostly Council/PMS decision -- like using
IUSE='foo@#*$@' instead of IUSE_RUNTIME='foo'.

Another thing is implementing it. But if it's deferred right now, I
doubt it's going to move on until the last vote. Zac used to be pretty
positive about it but nobody started trying to implement it. I'd say
the initial vote may happen on the idea now, and if necessary,
the implementation may be postponed into next EAPI later.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] EAPI6 Features

[Ulrich Mueller]

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

>>>>> On Mon, 9 Jun 2014, Michał Górny wrote:

> [...] IUSE_RUNTIME [...]

> Another thing is implementing it. But if it's deferred right now,
> I doubt it's going to move on until the last vote. Zac used to be
> pretty positive about it but nobody started trying to implement it.

I'd rather avoid adding a feature to EAPI 6 where we don't have a
proof of concept at least.

We made this mistake in EAPI 3 and it was endlessly delayed. (What was
originally intended to be EAPI 3 is now called EAPI 4, and at least
one of its features was further delayed until EAPI 5.)

> I'd say the initial vote may happen on the idea now, and if
> necessary, the implementation may be postponed into next EAPI later.

We can vote and give the go-ahead for it, and if IUSE_RUNTIME is
ready in time, then it can be part of EAPI 6. But please, let's keep
it separate from the EAPI, for the time being.

Ulrich

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

Re: [gentoo-project] EAPI6 Features

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/06/14 09:04 AM, Rich Freeman wrote:
> Most of the proposed EAPI6 features seem ripe for acceptance, but
> I figured I'd comment on a few here in case others want to weigh
> in.
>> b) User patches Bug #475288 [15], PMS wording [16] - Needs 4a) -
>> Current wording of the spec requires that every ebuild must 
>> include a call to the function in src_prepare, which is 
>> controversial. - Names "apply_user_patches" or "eapply_user" have
>> been suggested.
>> 
> 
> I'm generally fine with it (we can bikeshed the name to death
> later), but is there any reason to not just simply apply the
> patches after src_prepare is done and not make maintainers call it?
> If we're concerned about sequencing with other activities in
> src_prepare then that is fine - I don't have a big problem with it
> being a fatal error if it doesn't get called.


General guidelines for epatch_user is that it should be placed after
all ${S} manipulation but before eautoreconf.  Otherwise anything that
modifies configure.ac won't take effect.

If src_prepare is defined, that would mean it'd have to be put right
in the middle, still.  If it isn't defined, then either an eclass
would need to handle it as appropriate (i think many do;
autotools-utils.eclass iirc has some code for this?), or the default
src_prepare phase function would need to get a -lot- more complicated
in order to handle patches that touch certain build-systems.

Or would we just ban build-system patches from user patches?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlOVxU4ACgkQ2ugaI38ACPDiawD+KVaaVq5EKS9Gj+KVe6U0mjgP
kZhVJEzPUuGDq+MygzgA/i7t43Uq4oIV4USZzTFCPRv9gtNFD8IOvx5B1P9bO8Ck
=bsWX
-----END PGP SIGNATURE-----

[gentoo-project] Re: EAPI6 Features

[Jonathan Callen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 06/09/2014 10:31 AM, Ian Stakenvicius wrote:
> On 08/06/14 09:04 AM, Rich Freeman wrote:
>> Most of the proposed EAPI6 features seem ripe for acceptance,
>> but I figured I'd comment on a few here in case others want to
>> weigh in.
>>> b) User patches Bug #475288 [15], PMS wording [16] - Needs 4a)
>>> - Current wording of the spec requires that every ebuild must 
>>> include a call to the function in src_prepare, which is 
>>> controversial. - Names "apply_user_patches" or "eapply_user"
>>> have been suggested.
>>> 
> 
>> I'm generally fine with it (we can bikeshed the name to death 
>> later), but is there any reason to not just simply apply the 
>> patches after src_prepare is done and not make maintainers call
>> it? If we're concerned about sequencing with other activities in 
>> src_prepare then that is fine - I don't have a big problem with
>> it being a fatal error if it doesn't get called.
> 
> 
> General guidelines for epatch_user is that it should be placed
> after all ${S} manipulation but before eautoreconf.  Otherwise
> anything that modifies configure.ac won't take effect.
> 
> If src_prepare is defined, that would mean it'd have to be put
> right in the middle, still.  If it isn't defined, then either an
> eclass would need to handle it as appropriate (i think many do; 
> autotools-utils.eclass iirc has some code for this?), or the
> default src_prepare phase function would need to get a -lot- more
> complicated in order to handle patches that touch certain
> build-systems.
> 
> Or would we just ban build-system patches from user patches?
> 
> 

Just as a thought, perhaps we might add another phase, named like
"src_postpatch" (open to bikesheding), and have the `eapply_user`
called automatically between src_prepare and src_postpatch.  Any
post-user patch code (like eautoreconf) would then go in src_postpatch.

Thoughts?

- -- 
Jonathan Callen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJTldLZAAoJELHSF2kinlg4RqQP/RviMdnLAGRAy60m+qEDWy3C
ZvANn6sIjQtcXU37aX5Li1/7QC+RGqD6w7KLElJpL8D4MSL1ga8ORw5NY4VE+But
XB7n8mpzZZpxU7IHxfZ4gLMmz4OHXDQP34LNmxzVffftU/+H9U0k7WKeNGLL4C1H
ZBB8NkyLwGzlfIDQfCsFoDJCl5ebUi0ecijPVHOucuBwyPMTTJFg92fm8r/5vJ+C
F+N0+LoGzyBX0G9Xp/Ygtd69wALxpqv05g4zRdpAu8WaBZ+2s6SiuBif3DIAFykC
PurzfwSFqIk0rtF2p27W3WFAAXV7Zam1b7Kadw6BnrfZxmHsurgbvTHk5J309Z2S
J+9P5oIH2dTzXhV9Npk0kRHoMPxOQWMeXRQ9f9fAmFgPyLnTzfLBgtAQMIdGba1W
COnIk1Je3lfAv98NGv1hvZNOe8N8NbdSaf2kkfDFtppCVOHvaWVAhBQ0V0rJO92Q
1i9h53XwTxOk6aKkUgOsiW/qgIvx8wgLuVKOJd5ADR/4FHvlJbjlI5b+K+eV07Vv
wk/I8FsopEJdCX9r4oCecYRk1OwY5Xz+T8sZhrjQXISxQv38Byn8v+1h81MT/K2K
a0l/BqAplRv7SRkB4hkJq/azK70dgulIFDN/aQiUgjgGxedjyPEMFLN2Sy10va6g
bHYZ+Xwx7/pXIq5kXy9s
=Bhve
-----END PGP SIGNATURE-----

[gentoo-project] Re: EAPI6 Features

[Ulrich Mueller]

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

>>>>> On Mon, 09 Jun 2014, Jonathan Callen wrote:

> Just as a thought, perhaps we might add another phase, named like
> "src_postpatch" (open to bikesheding), and have the `eapply_user`
> called automatically between src_prepare and src_postpatch. Any
> post-user patch code (like eautoreconf) would then go in
> src_postpatch.

> Thoughts?

As I said before, I believe that the package manager shouldn't perform
any magic operations between src_* phases. Calling eapply_user like
this is effectively an additional phase, so it's conceptually cleaner
to make it a regular phase function (e.g., src_userpatch) which would
be called between src_prepare and src_postpatch.

Ulrich

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

Re: [gentoo-project] Re: EAPI6 Features

[Michał Górny]

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

Dnia 2014-06-09, o godz. 18:23:21
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Mon, 09 Jun 2014, Jonathan Callen wrote:
> 
> > Just as a thought, perhaps we might add another phase, named like
> > "src_postpatch" (open to bikesheding), and have the `eapply_user`
> > called automatically between src_prepare and src_postpatch. Any
> > post-user patch code (like eautoreconf) would then go in
> > src_postpatch.
> 
> > Thoughts?
> 
> As I said before, I believe that the package manager shouldn't perform
> any magic operations between src_* phases. Calling eapply_user like
> this is effectively an additional phase, so it's conceptually cleaner
> to make it a regular phase function (e.g., src_userpatch) which would
> be called between src_prepare and src_postpatch.

Sounds insanely complex for a minor issue. What's the problem with
ebuilds calling 'default' in src_prepare() to get user patches applied
(and possibly ${PATCHES[@]} as well)?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Re: EAPI6 Features

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/06/14 12:31 PM, Michał Górny wrote:
> Dnia 2014-06-09, o godz. 18:23:21 Ulrich Mueller <ulm@gentoo.org>
> napisał(a):
> 
>>>>>>> On Mon, 09 Jun 2014, Jonathan Callen wrote:
>> 
>>> Just as a thought, perhaps we might add another phase, named
>>> like "src_postpatch" (open to bikesheding), and have the
>>> `eapply_user` called automatically between src_prepare and
>>> src_postpatch. Any post-user patch code (like eautoreconf)
>>> would then go in src_postpatch.
>> 
>>> Thoughts?
>> 
>> As I said before, I believe that the package manager shouldn't
>> perform any magic operations between src_* phases. Calling
>> eapply_user like this is effectively an additional phase, so it's
>> conceptually cleaner to make it a regular phase function (e.g.,
>> src_userpatch) which would be called between src_prepare and
>> src_postpatch.
> 
> Sounds insanely complex for a minor issue. What's the problem with 
> ebuilds calling 'default' in src_prepare() to get user patches
> applied (and possibly ${PATCHES[@]} as well)?
> 

Again, it's a bit of a special case this it's just 'one' build system,
but, what if either a user's patch changes configure.ac , but the
ebuild itself hasn't patched configure.ac and so doesn't eautoreconf
(or for that matter, doesn't even inherit autotools).

The 'default' src_prepare would need to be smart enough to know that
the patch is changing build system bits, and either trigger the
appropriate prepare commands (eautoreconf or similar) or at least
EQAWARN that the patch applied but won't take effect.  And technically
that eqawarn should only occur if there is no eautoreconf coming up in
src_prepare (which could very well happen -after- 'default')..

- -----

I read earlier that the proposal is saying that src_prepare() needs to
be implemented for every package; it may make sense to include
eclass-inherited implementations in this too, since I expect it would
be more palatable to i.e. force inherit autotools-utils than to force
a handwritten, previously-unneeded src_prepare


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

iF4EAREIAAYFAlOV5DQACgkQ2ugaI38ACPD1mAD/StbF40970Sorj2nr9SvBTqwf
rnl4spmgkTr26EECMMMA/ijDZEviIJfgUv2j7aeC5mhwAmMIKWz+NnBpQlMZ1jxf
=7/2K
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: EAPI6 Features

[Ulrich Mueller]

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

>>>>> On Mon, 9 Jun 2014, Michał Górny wrote:

> Dnia 2014-06-09, o godz. 18:23:21
> Ulrich Mueller <ulm@gentoo.org> napisał(a):

>> As I said before, I believe that the package manager shouldn't
>> perform any magic operations between src_* phases. Calling
>> eapply_user like this is effectively an additional phase, so it's
>> conceptually cleaner to make it a regular phase function (e.g.,
>> src_userpatch) which would be called between src_prepare and
>> src_postpatch.

> Sounds insanely complex for a minor issue. What's the problem with
> ebuilds calling 'default' in src_prepare() to get user patches
> applied (and possibly ${PATCHES[@]} as well)?

Calling it in src_prepare() is perfectly fine with me. The only thing
I'm saying is that we shouldn't call eapply_user outside of a phase
function, whatever that phase function will be.

Ulrich

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

Re: [gentoo-project] Re: EAPI6 Features

[Jeroen Roovers]

On Mon, 9 Jun 2014 18:31:27 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Sounds insanely complex for a minor issue. What's the problem with
> ebuilds calling 'default' in src_prepare() to get user patches applied
> (and possibly ${PATCHES[@]} as well)?

Because the nicer solution is to not call some_function() in every
single ebuild in the tree that happens to stray from the default
src_prepare().

The problem is in what needs to happen after epatch_user(). If it turns
out some files need to be re-generated, then that would call for a
post-src_prepare() function (src_regen() perhaps) that all the
eautoreconf and equivalent calls get moved away to. Which then leads to
problems in determining whether that's needed, and to the user having
no proper way to force it as of now.


     jer