public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review
Date: Mon, 19 Oct 2015 15:49:06 -0400	[thread overview]
Message-ID: <CAGfcS_n1cxBO=aQC8q5JiAQtfdx3GfeAzGpK9eq3boUYQUUiSg@mail.gmail.com> (raw)
In-Reply-To: <20151019202816.694b344f@gentoo.org>

On Mon, Oct 19, 2015 at 2:28 PM, Alexis Ballier <aballier@gentoo.org> wrote:
>
> However, as you say, putting it in cmake-utils needs to be properly
> thought so that it doesn't conflict with other eclasses: Hence the need
> to properly define what eclasses should call eapply_user and apply
> patches and what should not.
>

That is my main concern.  Maybe a package uses cmake and ant.  Patches
could affect either.  With an automagic design you might have to run
half of each src_configure, then apply patches, then run the other
half of each src_configure.

> Your initial argument was very convincing, but under those conditions,
> it seems way much saner to make eapply_user idempotent and be done.
> (and maybe in addition require informally that eapply_user is called
> after applying patches, but that'd fall under good practices rather
> than rules)

The only danger here is that later phase functions to run would be
operating on already-patched sources, when they expect to be running
on unpatched sources.  I imagine that usually wouldn't be a problem,
but it of course could be one.

I do get your analogy to eapply_user not being in the default phase function.

This all falls into that general category of correctness vs
convenience.  It is more convenient if you can just call eapply_user
at a suboptimal point and not have to mess with your ebuilds.  The
same argument could be made for running all the inherited eclass phase
functions and not just one of them.  The issue is that this can break
in lots of hard-to-predict ways.  I'd rather see things refactored to
deal with this in a more sane manner.

That actually makes me wonder if the better solution is to add another
phase - such as src_postprepare or something like that, where you'd
run autotools or whatever.  If that were done then you could also make
hasufell happy by just having the PM do the patching after
src_prepare.  Maybe that can go in EAPI7.  :)

-- 
Rich


  reply	other threads:[~2015-10-19 19:49 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <22049.17676.1822.986579@a1i15.kph.uni-mainz.de>
2015-10-17 12:19 ` [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review Jason A. Donenfeld
2015-10-17 12:21   ` Jason A. Donenfeld
2015-10-17 12:24   ` Michał Górny
2015-10-17 12:28     ` hasufell
2015-10-17 12:52       ` Ulrich Mueller
2015-10-17 12:56         ` hasufell
2015-10-17 13:07           ` Ulrich Mueller
2015-10-17 15:22             ` hasufell
2015-10-17 16:40               ` Alexis Ballier
2015-10-17 22:16         ` Rich Freeman
2015-10-18  8:33           ` Alexis Ballier
2015-10-18  9:54           ` Ulrich Mueller
2015-10-18  9:56             ` Alexis Ballier
2015-10-18 10:13             ` Michał Górny
2015-10-18 10:17               ` Ulrich Mueller
2015-10-18 10:49                 ` Rich Freeman
2015-10-19  7:12                 ` Alexis Ballier
2015-10-19  7:22                   ` Anthony G. Basile
2015-10-19  7:28                     ` Alexis Ballier
2015-10-19  8:25                     ` Ulrich Mueller
2015-10-19  8:31                       ` Alexis Ballier
2015-10-19  7:58                   ` Michał Górny
2015-10-19  8:04                     ` Alexis Ballier
2015-10-19  8:09                       ` Michał Górny
2015-10-19  8:17                         ` Alexis Ballier
2015-10-19  8:07                     ` Anthony G. Basile
2015-10-19 22:07                     ` Andreas K. Huettel
2015-10-19 12:38                   ` Rich Freeman
2015-10-19 13:34                     ` Alexis Ballier
2015-10-19 13:51                       ` Rich Freeman
2015-10-19 14:21                         ` Alexis Ballier
2015-10-19 17:17                           ` Rich Freeman
2015-10-19 18:28                             ` Alexis Ballier
2015-10-19 19:49                               ` Rich Freeman [this message]
2015-10-20  7:51                                 ` Alexis Ballier
2015-10-20  8:57                                   ` Rich Freeman
2015-10-20  9:22                                     ` Alexis Ballier
2015-10-20 10:00                                       ` Rich Freeman
2015-10-20 10:25                                         ` Alexis Ballier
2015-10-21  1:24                                           ` Duncan
2015-10-21  7:29                                             ` Alexis Ballier
2015-10-18 10:36             ` Alexis Ballier
2015-10-20  7:47         ` Daniel Campbell
2015-10-20  8:00           ` Alexis Ballier
2015-10-17 12:42     ` Ulrich Mueller
2015-10-17 12:25   ` hasufell
2015-10-17 12:38     ` Rich Freeman
2015-10-17 12:49       ` hasufell
2015-10-17 12:56         ` Rich Freeman
2015-10-17 13:02           ` hasufell
2015-10-17 13:47         ` Alexis Ballier
2015-10-17 15:00           ` hasufell
2015-10-17 16:07             ` Anthony G. Basile
2015-10-17 16:35               ` Alexis Ballier
2015-10-17 18:03         ` Ciaran McCreesh
2015-10-18 11:37           ` hasufell
2015-10-18 11:43             ` Rich Freeman
2015-10-18 12:05               ` hasufell
2015-10-18 12:24                 ` Rich Freeman
2015-10-17 12:51       ` Michał Górny
2015-10-17 19:15         ` Rich Freeman
2015-10-17 20:08 ` Alexis Ballier
2015-10-17 20:47   ` Ulrich Mueller
2015-10-18  8:31     ` Alexis Ballier
2015-10-18  8:48       ` Michał Górny
2015-10-18  9:23         ` Alexis Ballier
2015-10-18 10:07           ` Michał Górny
2015-10-18 10:34             ` Alexis Ballier
2015-10-18 11:54           ` Andreas K. Huettel
2015-10-18 11:57             ` Alexis Ballier
2015-10-18 12:44       ` Ciaran McCreesh
2015-10-18 13:01         ` Rich Freeman
2015-10-18 18:00         ` Alexis Ballier
2015-10-18 18:06           ` Ciaran McCreesh
2015-10-18 18:19             ` Alexis Ballier
2015-10-18 18:36               ` Ciaran McCreesh
2015-10-18 19:20                 ` Alexis Ballier
2015-10-17 21:24   ` Michał Górny
2015-10-18  8:47     ` Alexis Ballier
2015-10-18  9:01       ` Michał Górny
2015-10-18  9:34         ` Alexis Ballier
2015-10-18 10:09           ` Michał Górny
2015-10-18 10:31             ` Alexis Ballier
2015-10-20 18:55 ` [gentoo-dev] utilizing BASH_COMPAT to smooth upgrades Mike Frysinger
2015-10-20 22:03   ` Ulrich Mueller
2015-10-20 22:51     ` Mike Frysinger
2015-10-21  7:34       ` [gentoo-dev] [PATCH] Recommend setting the bash compatibility level. (was: Re: utilizing BASH_COMPAT to smooth upgrades) Ulrich Mueller
2015-10-22 13:55         ` [gentoo-dev] " Mike Frysinger
2015-10-22 15:00           ` Ulrich Mueller
2015-10-22 15:21             ` Mike Frysinger

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='CAGfcS_n1cxBO=aQC8q5JiAQtfdx3GfeAzGpK9eq3boUYQUUiSg@mail.gmail.com' \
    --to=rich0@gentoo.org \
    --cc=gentoo-dev@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