Given a file protected by configprotect, (/etc/sudoers in this case), merged by sudo. Then seemant-1.0.ebuild comes along and modifies /etc/sudoers; because there is no record of /etc/sudoers in confmem everything is fine. Then I delete the ._cfg file because I don't like his changes. Later I decide I want them, so I remerge seemant-1.0.ebuild, only to find no ._cfg file was generated. This is due to confmem, where the dict in /var/lib/portage/config holds an md5sum of the livefs and it differs from the md5sum in srcroot ($IMAGE, $D). however instead of generating a ._cfg file like you'd expect, portage tries to be smart and guess that you didn't want it before, so you don't want it now, and skips it. Turning on --noconfmem will turn this behavior off; however I don't see a reason for the behavior.
Created attachment 94656 [details, diff] Removes annoying section of treewalk
(In reply to comment #0) > Later I decide I want them, so I remerge seemant-1.0.ebuild, only to find no > ._cfg file was generated. I don't think this is the common use case. For the most time when people remerge or update a package they don't want to apply/discard the same config file changes every time.
(In reply to comment #2) > (In reply to comment #0) > > Later I decide I want them, so I remerge seemant-1.0.ebuild, only to find no > > ._cfg file was generated. > > I don't think this is the common use case. For the most time when people > remerge or update a package they don't want to apply/discard the same config > file changes every time. Ok I can agree (somewhat) with that; but I'm trying to think of a seperate case when I (intentially) changed the file in srcroot such that mymd5 would be different (by editing the ebuilds seemant gave me to add more crap into /etc/sudoers) and it still didn't trigger a ._cfg000 file; I'll test again for this case. If nothing else, a check further in treewalk prevents people from seeing the "-o-" that this code supposed to generate and instead they get a ">>>" which means something completely different.
(In reply to comment #2) > (In reply to comment #0) > > Later I decide I want them, so I remerge seemant-1.0.ebuild, only to find no > > ._cfg file was generated. > > I don't think this is the common use case. For the most time when people > remerge or update a package they don't want to apply/discard the same config > file changes every time. Is it really the package manager's job to provide this kind of "smart" behavior though? It could also be implemented separately within tools such as etc-update or dispatch-conf. Basically, the description of this bug seems to be to punt the confmem feature entirely. If we decide to punt it, the patch should remove all traces (not just disable it).
The confmem code has be refactored (svn r4450 and r4453) and released in 2.1.2_pre1. If there were any bugs in the old logic, I'm pretty sure they've been fixed in the refactoring. Note that it's possible to set EMERGE_DEFAULT_OPTS="--noconfmem" in make.conf.
