>>>>> On Sat, 28 Aug 2021, Michał Górny wrote:

> 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:

> xdg.eclass:

>   EXPORT_FUNCTIONS src_prepare

> ecm-1.eclass:

>   inherit xdg
>   EXPORT_FUNCTIONS src_prepare

> ecm-2.eclass:

>   EXPORT_FUNCTIONS src_prepare
>   inherit xdg


> Now, ecm-1.eclass produces consistent behavior across all PMs --
> ecm-1_src_prepare takes precedence.  However, ecm-2.eclass is not
> consistent:

> - Portage will take ecm-2_src_prepare, i.e. applies precedence based
> on inherit order and not actual call order

But it is the reverse of normal inherit order. That is, if an ebuild
does:

  inherit ecm-2 xdg

then xdg takes precedence. However, in your second example above, the
inherit order is the same (ecm-2 first, xdg second), but with Portage
the _earlier_ eclass takes precedence.

> - PkgCore and Paludis will take xdg_src_prepare since its
> EXPORT_FUNCTIONS are called later (since the inherit is done later).

Which is consistent with the behaviour when both eclasses are inherited
directly from the ebuild.

> Apparently, the Portage behavior was changed in 2009 [1].  PMS is not
> very clear on what should happen.

Can you provide any pointer to a discussion of that Portage change in
gentoo-dev?


> Therefore:

> 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.

> WDYT?

Not sure, but if we follow [2] then this qualifies as a Portage bug.
I'd really hate to retroactively change the spec to "undefined".

Ulrich


> [1] 
> https://github.com/gentoo/portage/commit/06d4433e8b8be60d606733b9e23f57f8a5869d8f

[2] https://projects.gentoo.org/council/meeting-logs/20160313-summary.txt

Attachment: signature.asc
Description: PGP signature

Reply via email to