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.
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.
--
ionen
signature.asc
Description: PGP signature
