| 1 |
>>>>> On Sat, 28 Aug 2021, Michał Górny wrote: |
| 2 |
|
| 3 |
> I've been informed of a slight inconsistency in package manager behavior |
| 4 |
> that affects combining EXPORT_FUNCTIONS with inherit (by ionic, thanks |
| 5 |
> for the report!). Please consider the three following snippets: |
| 6 |
|
| 7 |
> xdg.eclass: |
| 8 |
|
| 9 |
> EXPORT_FUNCTIONS src_prepare |
| 10 |
|
| 11 |
> ecm-1.eclass: |
| 12 |
|
| 13 |
> inherit xdg |
| 14 |
> EXPORT_FUNCTIONS src_prepare |
| 15 |
|
| 16 |
> ecm-2.eclass: |
| 17 |
|
| 18 |
> EXPORT_FUNCTIONS src_prepare |
| 19 |
> inherit xdg |
| 20 |
|
| 21 |
|
| 22 |
> Now, ecm-1.eclass produces consistent behavior across all PMs -- |
| 23 |
> ecm-1_src_prepare takes precedence. However, ecm-2.eclass is not |
| 24 |
> consistent: |
| 25 |
|
| 26 |
> - Portage will take ecm-2_src_prepare, i.e. applies precedence based |
| 27 |
> on inherit order and not actual call order |
| 28 |
|
| 29 |
But it is the reverse of normal inherit order. That is, if an ebuild |
| 30 |
does: |
| 31 |
|
| 32 |
inherit ecm-2 xdg |
| 33 |
|
| 34 |
then xdg takes precedence. However, in your second example above, the |
| 35 |
inherit order is the same (ecm-2 first, xdg second), but with Portage |
| 36 |
the _earlier_ eclass takes precedence. |
| 37 |
|
| 38 |
> - PkgCore and Paludis will take xdg_src_prepare since its |
| 39 |
> EXPORT_FUNCTIONS are called later (since the inherit is done later). |
| 40 |
|
| 41 |
Which is consistent with the behaviour when both eclasses are inherited |
| 42 |
directly from the ebuild. |
| 43 |
|
| 44 |
> Apparently, the Portage behavior was changed in 2009 [1]. PMS is not |
| 45 |
> very clear on what should happen. |
| 46 |
|
| 47 |
Can you provide any pointer to a discussion of that Portage change in |
| 48 |
gentoo-dev? |
| 49 |
|
| 50 |
|
| 51 |
> Therefore: |
| 52 |
|
| 53 |
> 1. I'd like to propose that we explicitly require all inherits to happen |
| 54 |
> before EXPORT_FUNCTIONS. This will ensure consistent behavior across |
| 55 |
> all package managers. |
| 56 |
|
| 57 |
> 2. I'd like to ask your opinion whether we should: |
| 58 |
|
| 59 |
> a. revert the Portage behavior to be consistent with PkgCore/Paludis |
| 60 |
|
| 61 |
> b. update PMS to identify the behavior as 'undefined', i.e. either |
| 62 |
> solution is correct. |
| 63 |
|
| 64 |
> WDYT? |
| 65 |
|
| 66 |
Not sure, but if we follow [2] then this qualifies as a Portage bug. |
| 67 |
I'd really hate to retroactively change the spec to "undefined". |
| 68 |
|
| 69 |
Ulrich |
| 70 |
|
| 71 |
|
| 72 |
> [1] https://github.com/gentoo/portage/commit/06d4433e8b8be60d606733b9e23f57f8a5869d8f |
| 73 |
|
| 74 |
[2] https://projects.gentoo.org/council/meeting-logs/20160313-summary.txt |
Archives