public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ian Stakenvicius <axs@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] Re: EAPI6 Features
Date: Mon, 09 Jun 2014 12:43:32 -0400	[thread overview]
Message-ID: <5395E434.9020903@gentoo.org> (raw)
In-Reply-To: <20140609183127.37705e89@pomiot.lan>

-----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-----


  reply	other threads:[~2014-06-09 16:43 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
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 [this message]
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=5395E434.9020903@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