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
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
