While re-emerging a already installed package, portage calls postrm function before postinst. If you have /etc/portage/bashrc hooks both on postinst and postrm, this duplicates the phase meaning: At reinstallation ( simple merge ): postrm 1st --> postinst 2nd At removal ( emerge -C / --unmerge ) : just postrm 1st Reproducible: Always Steps to Reproduce: 1. setup /etc/portage/bashrc to have postrm and postinst ebuild phases verbose 2. emerge a already installed package 3. observe how postrm is called before postinst Actual Results: postrm is called before postinst while re-emerging a already-installed package Expected Results: Package installation should not call postrm before postinst ( details bellow ) Replacement for the function with the same functionality should be involved, but just different name, i.e. mid_post_rm instead of postrm while re-emerging the same package If you have /etc/portage/bashrc hook that contain both EBUILD_PHASE postrm and postinst, the postrm function should be called after total removal of to-be-replaced-package. There is no workaround unless you create a wrapper over Portage.
Created attachment 511278 [details] Portage bashrc hook example
According to PMS, postrm is supposed to be called before postinst. https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-1120009.2
Created attachment 511280 [details] Actual postrm before postinst at package re-emerge
@Mike Indeed, that's why I consider it a core bug. Either postrm should not be called before postinst, or a different EBUILD_PHASE can be called in the same /etc/portage/bashrc hook to take its place as the right "post removal hook" i.e. If I have both a postinst and a postrm in the /etc/portage/bashrc, both doing things totally separate from one another, postrm will still be called, even though it's about re-emerging a package. TL;DR: There is a possibility things could get removed without my permission while a re-emerging happens due to the fact that I have a postrm in place.
You can probably use some conditional logic based on the REPLACING_VERSIONS and REPLACED_BY_VERSION variables available since EAPI 4: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-12000011.1.2 We can't change the behavior for current EAPIs, but you can file a "Future EAPI" bug and make it block this tracker: https://bugs.gentoo.org/174380
@Zac Yeah, using REPLACED_* variables helped tremendously. Yet still in the case of re-emerge, I will have to do a separate workaround. Thank you! I will post the blocker against the new EAPI.
