The CONTENTS file, made not only for tracking files, but also checking for modifications, doesn't take files in CONFIG_PROTECT into account. I propose that a new object type "cfg" be created for the CONTENTS file. This would safely allow things such as chkcontents to not falsely report config files as being modified (which they need to be generally). The "cfg" object type should probably be something like dir, listing the filename and nothing more.
would rather have contents abstraction in place before trying this. This isnt' stable material either way, since older portage versions won't know wth to do with cfg objs.
I disagree with mixing it into the CONTENTS database, whatever its representation. Packages can augment CONFIG_PROTECT via env.d so what portage records as being config files and not will be incorrect. Users can also modify CONFIG_PROTECT_MASK which will then lead to portage not having enough information when it hits "cfg" files within those directories. This is also counter to the separating of CONFIG_PROTECT into merge-time and unmerge-time parts. Any changes along these lines belong in the end tools. chkcontents does not falsely report config files as being changed. It's simply a case of you not caring that they have changed. Fix it by adding an option to ignore CONFIG_PROTECT to chkcontents, not by destroying necessary information.
