From: Ian Stakenvicius <axs@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] EAPI6 Features
Date: Mon, 09 Jun 2014 10:31:42 -0400 [thread overview]
Message-ID: <5395C54E.9020802@gentoo.org> (raw)
In-Reply-To: <CAGfcS_mQXrGoi3cs_K+dBtbLaMUytB_vyNAEmf+G+o1cH+qM5g@mail.gmail.com>
-----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-----
next prev parent reply other threads:[~2014-06-09 14:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-08 13:04 [gentoo-project] EAPI6 Features Rich Freeman
2014-06-08 14:38 ` Ulrich Mueller
2014-06-08 15:09 ` Rich Freeman
2014-06-08 19:15 ` Pacho Ramos
2014-06-08 20:56 ` Ulrich Mueller
2014-06-09 8:50 ` Pacho Ramos
2014-06-08 21:49 ` Michał Górny
2014-06-08 15:29 ` Jeroen Roovers
2014-06-08 16:56 ` Ulrich Mueller
2014-06-08 17:22 ` Andreas K. Huettel
2014-06-08 17:26 ` Ciaran McCreesh
2014-06-08 17:28 ` Ulrich Mueller
2014-06-08 21:40 ` Michał Górny
2014-06-08 22:58 ` Rich Freeman
2014-06-09 2:57 ` Michał Górny
2014-06-09 10:12 ` Ulrich Mueller
2014-06-09 14:31 ` Ian Stakenvicius [this message]
2014-06-09 15:29 ` [gentoo-project] " Jonathan Callen
2014-06-09 16:23 ` Ulrich Mueller
2014-06-09 16:31 ` Michał Górny
2014-06-09 16:43 ` Ian Stakenvicius
2014-06-09 16:47 ` Ulrich Mueller
2014-06-09 19:20 ` Jeroen Roovers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5395C54E.9020802@gentoo.org \
--to=axs@gentoo.org \
--cc=gentoo-project@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox