Say, you prelink, and then decide you don't want to anymore, so you emerge -C prelink. After this portage will no longer find the prelink binary, so it will not be able to use it to check unlinked md5 sums of the files, thus leaving them behind. Reproducible: Always Steps to Reproduce: 1. emerge prelink && env-update 2. prelink -amR 3. emerge -C prelink Actual Results: /usr/bin/execstack was not removed (wrong md5 sum) Expected Results: /usr/bin/execstack should have been removed as it is part of the package selected for unmerging and has only been prelinked To me a simple solution sounds like making the unmerge of prelink (emerge -C prelink) un-prelink (prelink -aumR) all the files on the system so their md5 sums will be correct again.
I cannot add this to the ebuild that easily as I need to differentiate when prelink is being unmerged as it is being upgraded or removed compleatly. Any ideas? ( I have known of this issue for a while but I have happily ignored it )
portage uses md5 + mtime to determine what should be removed. until it does refcounts, this is a unsolvable issue due to prelink's meddling outside of portage's knowledge...
Could you atleast add a warning to the prelink doc on gentoo.org and to the end of the emerge process of prelink? I would be very grateful.
Currently, portage_checksum.prelink_capable defaults to True as long as the prelink binary exists (reminiscent of autouse or something). Perhaps it would be better if the user had to explicitly enable it with FEATURES="prelink". This should help prevent users from "shooting themselves in the foot".
Closing again, see Comment #2. Nothing to be done here at the moment.
