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