| 1 |
On Sun, 2021-08-29 at 12:23 -0500, William Hubbs wrote: |
| 2 |
> On Sat, Aug 28, 2021 at 06:35:06PM +0200, Michał Górny wrote: |
| 3 |
> > Hi, |
| 4 |
> > |
| 5 |
> > I've been informed of a slight inconsistency in package manager behavior |
| 6 |
> > that affects combining EXPORT_FUNCTIONS with inherit (by ionic, thanks |
| 7 |
> > for the report!). Please consider the three following snippets: |
| 8 |
> |
| 9 |
> ... |
| 10 |
> |
| 11 |
> > 1. I'd like to propose that we explicitly require all inherits to happen |
| 12 |
> > before EXPORT_FUNCTIONS. This will ensure consistent behavior across |
| 13 |
> > all package managers. |
| 14 |
> > |
| 15 |
> > 2. I'd like to ask your opinion whether we should: |
| 16 |
> > |
| 17 |
> > a. revert the Portage behavior to be consistent with PkgCore/Paludis |
| 18 |
> > |
| 19 |
> > b. update PMS to identify the behavior as 'undefined', i.e. either |
| 20 |
> > solution is correct. |
| 21 |
> |
| 22 |
> I would go with 1 and 2 b, but I also propose another option for the |
| 23 |
> next eapi which may be a bit controversial. |
| 24 |
> |
| 25 |
> Starting with eapi 9, make export_functions a noop (you can't remove it |
| 26 |
> until all eclasses/ebuilds only support eapis that don't require it). |
| 27 |
> |
| 28 |
> I understand that this is controversial, because it would require a lot |
| 29 |
> of work to convert ebuilds to eapi 9, but it would eliminate this |
| 30 |
> ambiguity/inconsistency in the future because it would require all |
| 31 |
> ebuilds to have phase functions unless they can use the default phases |
| 32 |
> the eapis provide. |
| 33 |
> |
| 34 |
> Thoughts? |
| 35 |
> |
| 36 |
|
| 37 |
It would not only require work to convert ebuilds but it would also |
| 38 |
require a lot of work when writing new ebuilds. The developers would |
| 39 |
have to explicitly remember to call the correct set of phases for each |
| 40 |
inherited eclass, and this is a lot of work for the lot of otherwise |
| 41 |
trivial ebuilds. |
| 42 |
|
| 43 |
Not to mention the quite obvious risk of silent breakage when people |
| 44 |
forget to call a phase function. Just imagine that all python-single-r1 |
| 45 |
ebuilds would have to call python-single-r1_pkg_setup explicitly or they |
| 46 |
would silently fall back to random Python version that's going to work |
| 47 |
90% of the time, so people won't even notice that the ebuild is broken. |
| 48 |
|
| 49 |
In the end, this would naturally lead to people hacking this around by |
| 50 |
reinventing EXPORT_FUNCTIONS inside eclasses. In the best case, we'd |
| 51 |
see functions like 'cmake_export_phases' -- which maybe, just maybe, |
| 52 |
would be better than implicit exports. |
| 53 |
|
| 54 |
-- |
| 55 |
Best regards, |
| 56 |
Michał Górny |
Archives