On 02/06/2024 18.40, Ulrich Mueller wrote:
>>>>>> On Sun, 02 Jun 2024, Florian Schmaus wrote:
> 
>>> 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.
> 
> It would break most ebuilds that inherit elisp and readme.gentoo-r1,
> because elisp_pkg_postinst would no longer be called.

You are right. I had not considered this case. Interesting.

We could maybe define a pre-inherit variable 
README_GENTOO_EXPORT_PHASE_FUNCS to opt-in to the new behavior. Is there 
any prior art regarding this?

However, it feels like my hunch was right and this is just another 
argument why it should be a new eclass.

But if you have any suggestions on how to best deal with this, then 
please let me know.

- Flow