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
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
postrm is called before postinst while re-emerging a already-installed package
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.
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.
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:
We can't change the behavior for current EAPIs, but you can file a "Future EAPI" bug and make it block this tracker:
Yeah, using REPLACED_* variables helped tremendously.
Yet still in the case of re-emerge, I will have to do a separate workaround.
I will post the blocker against the new EAPI.