Version of portage: sys-apps/portage-2.2.0_alpha171 When binary packages that have been created by "quickpkg --include-config=y" are merged, files within the scope of CONFIG_PROTECT are treated as "unmodified" by portage even if they had been modified on the host system prior to package creation. As a consequence, all files in a given package will be overwritten or removed during upgrade/reinstall or unmerge operations, respectively, unless they have changed since the binary was merged. This happens because /var/lib/portage/config is populated with current md5 hash values of the newly installed files. A necessary prerequisite is that "config-protect-if-modified" is set in $FEATURES, which is the default. This seems like a pretty severe bug to me. Consider for example: quickpkg --include-config=y <list of all installed atoms> emerge -eK world emerge -e world The second emerge would clobber all existing config files (unless "config-protect-if-modified" is explicitly unset in FEATURES). I'm not familiar with the internal details of portage, so I can't suggest an optimal method of handling the issue. However, I observe that md5 hashes from the original files are preserved in /var/db/pkg/${CATEGORY}/${PN}-${PVR}/CONTENTS. Perhaps those could be taken into account. The current handling of protected files isn't very robust and is somewhat dangerous.
I don't see any convenient way to protect against this kind of problem. The same kind of problem also prevents quickpkg --include-unmodified-config from knowing if a config file was modified by a user prior to a previous quickpkg/install cycle (that's why it's disabled be default, just like --include-config is). We can add warnings about these behaviors to the documentation for both options. I think that would be good enough. Because of quickpkg's inherent flaws, I would advise people to avoid using it whenever possible, and to use FEATURES=buildpkg instead.
*** Bug 586274 has been marked as a duplicate of this bug. ***