emaint cleanconfmem removes checksums of manually edited config files with the remark that the checksums do not match. Although this is true in some sense - the checksums do not match with the config file from the emerge - the checksum of the existing file is somewhere stored by portage to be checked if --noconfmem is not used. Emaint should recognize that the checksum of the existing file and of the corresponding database are the same, and so the checksum is not cleaned. I can see this, because portage would normally not try to install the (unmodified) config-file again, but after "emaint cleanconfmem" it does (i.e. it behaves as if --noconfmem would be specified at every portage call). This more aggressive behavior might also be useful for some occassions, but I would like to see a possibility that emaint really only removes obsolete data without modifying future behavior of emerge.
There are only 2 reasons for an entry to be considered for removal. 1) the config does not exist, so it is an obsolete entry. 2) the checksums don't match. This reason can not be tracked as to why without forcing all editing through a proxy app so it can be tracked correctly. Although it deletes entries that do not match. The next merge will add them back again. What I gathered from your comment is you would like it to default to only removing obsolete entries. With the new emaint re-write it is possible to have more than just --check, --fix options. Options can also be made to accept assignments. Both check and fix options have not and currently do not accept assignments. In this case there could be --obsolete-only, or --checksums options which could change the default behavior. Zac, what do you think
I think the appropriate behavior would be to only discard entries for files that don't exist, and that we don't need an option to control this.
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=6a4d36cf51ceac6e300a38b7e1272625e291c9a6
This is fixed in 2.1.11.13 and 2.2.0_alpha124.