> On 29 Aug 2021, at 19:41, Ionen Wolkens <io...@gentoo.org> wrote: > > On Sun, Aug 29, 2021 at 12:23:22PM -0500, William Hubbs wrote: >> On Sat, Aug 28, 2021 at 06:35:06PM +0200, Michał Górny wrote: >>> Hi, >>> >>> I've been informed of a slight inconsistency in package manager behavior >>> that affects combining EXPORT_FUNCTIONS with inherit (by ionic, thanks >>> for the report!). Please consider the three following snippets: >> >> ... >> >>> 1. I'd like to propose that we explicitly require all inherits to happen >>> before EXPORT_FUNCTIONS. This will ensure consistent behavior across >>> all package managers. >>> >>> 2. I'd like to ask your opinion whether we should: >>> >>> a. revert the Portage behavior to be consistent with PkgCore/Paludis >>> >>> b. update PMS to identify the behavior as 'undefined', i.e. either >>> solution is correct. >> >> I would go with 1 and 2 b, but I also propose another option for the >> next eapi which may be a bit controversial. >> >> Starting with eapi 9, make export_functions a noop (you can't remove it >> until all eclasses/ebuilds only support eapis that don't require it). >> >> I understand that this is controversial, because it would require a lot >> of work to convert ebuilds to eapi 9, but it would eliminate this >> ambiguity/inconsistency in the future because it would require all >> ebuilds to have phase functions unless they can use the default phases >> the eapis provide. >> >> Thoughts? > > If anything I'd personally prefer the rough opposite of this, in the > event multiple eclass export the same, have the package manager merge > them.
This is my preference too, if we're to go this route. It's similar to what was proposed in https://bugs.gentoo.org/516014, although this topic tends to lead to lots of different ideas (sometimes solving different problems!) > > e.g. rather than have `inherit cmake xdg` run xdg_src_prepare over > cmake's, would export: > > src_prepare() { > cmake_src_prepare > xdg_src_prepare > } > > unless the ebuild redefines it (which I imagine would often be because > of optional support, e.g. use lua &&, or occasional incompatibilities) > > Some ebuilds have special needs, but then there's all those generic > ebuilds that should stay nearly empty. best, sam
signature.asc
Description: Message signed with OpenPGP
