a.eclass: ``` EXPORT_FUNCTIONS src_prepare a_src_prepare() { ... default } ``` b.eclass: ``` EXPORT_FUNCTIONS src_prepare b_src_prepare() { ... default } ```` pkg.ebuild: ``` inherit a b src_prepare() { PATCHES=( pkg.patch ) a_src_prepare b_src_prepare } ``` b_src_prepare fails because the second default() wants to apply PATCHES again which fails of course.
What would you expect to happen instead? You probably just want to set PATCHES=() after the first call to a_src_prepare. Or better, call eapply yourself once at the top of src_prepare and leave PATCHES undefined.
I'd expect it to work naturally. I'm sure there are workarounds, but as calling default() twice doesn't make sense from the Portage's point of view, the only clean way is to handle it in Portage. It will also prevent other similar errors from occurring in the future EAPIs, which may change default src_prepare completely.
(In reply to Jan Chren (rindeal) from comment #2) > I'd expect it to work naturally. It's doing exactly what you've asked it to do =) > I'm sure there are workarounds, but as calling default() twice doesn't make sense from the Portage's point of view Why not? Conceivably, someone else could have solved this problem by doing, src_prepare() { PATCHES=( pkg.patch ) a_src_prepare PATCHES=() b_src_prepare } How would you fix it without breaking that code? In this case, a single eapply better conveys the intent and would be future-proof, but here's a harder one: in dev-lang/php, we create a few copies of the source tree, one for each "SAPI". Is it not valid to run the default src_prepare in each of those copies?
(In reply to Michael Orlitzky from comment #3) > > src_prepare() { > PATCHES=( pkg.patch ) > a_src_prepare > PATCHES=() > b_src_prepare > } > Oops, broken example. Try this one instead! src_prepare() { PATCHES=() a_src_prepare PATCHES=( pkg.patch ) b_src_prepare }
Another example from the PHP stuff. Right now php_init_slot_env is harmless, but it could legally and usefully contain slot-specific PATCHES. # @FUNCTION: php-ext-source-r3_src_prepare # @DESCRIPTION: # For each PHP slot, we initialize the environment, run the default # src_prepare() for PATCHES/eapply_user support, and then call # php-ext-source-r3_phpize. php-ext-source-r3_src_prepare() { for slot in $(php_get_slots); do php_init_slot_env "${slot}" default php-ext-source-r3_phpize done }
Portage follows PMS here. PMS defines how default works, and any discussion on changing Portage behavior is wrong without changing PMS in a new EAPI first. That said, the requested change doesn't make much sense. There are ebuilds intentionally calling default multiple times, e.g. in different directories. While it may sometimes be imperfect, it's at least predictable. 'default' that magically conditionally does nothing wouldn't be.
<PMS team lead> Currently PMS says that the default function "behaves as the default implementation for that EAPI". I am opposed to replacing this simple and clear definition by something complicated, especially when that new definition would violate the principle of least surprise. We have one function, namely eapply_user(), which is idempotent. The difference is that eapply_user _must_ be called once in the src_prepare phase, whereas default need not. So if default causes problems in an eclass, then this can be solved simply by not calling it (which isn't possible for eapply_user). </PMS team lead>
Closing per comment #7.
