On Sun, 2021-08-29 at 12:23 -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? >
It would not only require work to convert ebuilds but it would also require a lot of work when writing new ebuilds. The developers would have to explicitly remember to call the correct set of phases for each inherited eclass, and this is a lot of work for the lot of otherwise trivial ebuilds. Not to mention the quite obvious risk of silent breakage when people forget to call a phase function. Just imagine that all python-single-r1 ebuilds would have to call python-single-r1_pkg_setup explicitly or they would silently fall back to random Python version that's going to work 90% of the time, so people won't even notice that the ebuild is broken. In the end, this would naturally lead to people hacking this around by reinventing EXPORT_FUNCTIONS inside eclasses. In the best case, we'd see functions like 'cmake_export_phases' -- which maybe, just maybe, would be better than implicit exports. -- Best regards, Michał Górny
