On 02/06/2024 17.25, Ulrich Mueller wrote:
>>>>>> On Sun, 02 Jun 2024, Florian Schmaus wrote:
> 
>> Note that this changes readme.gentoo-r1.eclass to export phase
>> functions when it previously did not.
> 
> IMHO that's a very bad idea and will probably break ebuilds that rely
> on the current behaviour.

I pondered about this and its one of the reasons I'd rather start with a 
fresh eclass.

That said, worst case scenario I could came up with is that the elog 
message is printed twice. And this is also only the case if the ebuild 
has readme.gentoo_print_elog *not* in pkg_postinst. However, the 
readme.gentoo-r1.eclass documentation suggests you to put it in 
pkg_postinst.

And if an ebuild has readme.gentoo_print_elog *in* pkg_postinst, which 
should be true for nearly all ebuilds currently inheriting 
readme.gentoo-r1, then you don't use the newly exported pkg_postinst 
function (and the outcome of the exproted pkg_preinst is simply ignored).

Bottom line is: exporting the functions should do no harm.


 > (Also, readme.gentoo.eclass used to export phase functions, which was
 > removed in -r1. So you should have a good rationale for reverting this.)

I talked with pacho about this. The background back then was 
https://bugs.gentoo.org/520094, but this about src_install. At the end 
of the discussion with pacho, we both came to the conclusion that 
exporting pkg_preinst and pkg_postinst is not a problem.

Bottom line here is: eclasses exporting phase functions is not uncommon. 
I do not see any issue in this case, do you?

- Flow