Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 641868 - sys-apps/portage-2.3.x while re-emerging package postrm is called before postinst
Summary: sys-apps/portage-2.3.x while re-emerging package postrm is called before post...
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
Depends on:
Reported: 2017-12-21 01:07 UTC by Stefan Cristian Brindusa
Modified: 2017-12-21 01:34 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---

Portage bashrc hook example (bashrc_hooks_example,478 bytes, text/plain)
2017-12-21 01:10 UTC, Stefan Cristian Brindusa
Actual postrm before postinst at package re-emerge (detailed_postrm_before_postinst_remerge,1.78 KB, text/plain)
2017-12-21 01:11 UTC, Stefan Cristian Brindusa

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Cristian Brindusa 2017-12-21 01:07:18 UTC
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.
Comment 1 Stefan Cristian Brindusa 2017-12-21 01:10:59 UTC
Created attachment 511278 [details]
Portage bashrc hook example
Comment 2 Mike Gilbert gentoo-dev 2017-12-21 01:11:25 UTC
According to PMS, postrm is supposed to be called before postinst.
Comment 3 Stefan Cristian Brindusa 2017-12-21 01:11:55 UTC
Created attachment 511280 [details]
Actual postrm before postinst at package re-emerge
Comment 4 Stefan Cristian Brindusa 2017-12-21 01:15:53 UTC
@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.
Comment 5 Zac Medico gentoo-dev 2017-12-21 01:20:43 UTC
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:
Comment 6 Stefan Cristian Brindusa 2017-12-21 01:34:26 UTC

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.