Well, pretty much what the summary says. I modified /etc/init.d/gpm, so after the gpm downgrade, i had a /etc/init.d/._cfg0000_gpm. I did not modify /etc/init.d/xfs, so no ._cfg????_xfs. This is what i get if i try to locate the ebuild for both: nosferatu linux # epm -qf /etc/init.d/xfs xfree-4.2.0-r11 nosferatu linux # epm -qf /etc/init.d/gpm file /etc/init.d/gpm is not owned by any package nosferatu linux # Just to give two examples.
This is known and expected behavior. The ._cfg file is recorded in CONTENTS instead. I'm not sure I understand the problem you're experiencing.
Ok, this is maybe a bit much, but here is the CONTENTS from gpm in previous example: ----------------------------------snip---------------------------------- dir /usr dir /usr/lib obj /usr/lib/libgpm.a 345b69cdb96686db990af9fd986dfa96 1022449659 obj /usr/lib/libgpm.so.1.18.0 21d5b90f0de97bf076ef18ace3d281cb 1022449659 dir /usr/bin obj /usr/bin/mev 69cafe0a9a4f7bff1adcc3a0e0dd24f7 1022449659 obj /usr/bin/gpm-root 1fdb84d80e02f8f1089b1490f1862870 1022449659 obj /usr/bin/disable-paste 80f0aae98e2ab8894f158ce78532b02d 1022449659 dir /usr/sbin obj /usr/sbin/gpm 141550976ee83f71b43ba702b6660e01 1022449659 dir /usr/include obj /usr/include/gpm.h 2fa5d297cba7f545f7661e644ac76159 1022449659 dir /usr/share dir /usr/share/man dir /usr/share/man/man1 obj /usr/share/man/man1/mev.1.gz 1136f2c8f718c123cb2f461688f5a210 1022449659 obj /usr/share/man/man1/gpm-root.1.gz 5dc56e7f2b2f060fb02580c7615ba3ef 1022449659 obj /usr/share/man/man1/mouse-test.1.gz d6a0155d7bf279992538ca5283e02031 1022449659 dir /usr/share/man/man7 obj /usr/share/man/man7/gpm-types.7.gz 42e8d770c76030e09beb311b8593fda5 1022449659 dir /usr/share/man/man8 obj /usr/share/man/man8/gpm.8.gz bc33532f7ccc0b77b8c8b84fc80ba1a5 1022449659 dir /usr/share/info obj /usr/share/info/gpm.info.gz 479a8d280225d4880383da0bb624e0b1 1022449659 dir /usr/share/doc dir /usr/share/doc/gpm-1.19.6 obj /usr/share/doc/gpm-1.19.6/BUGS.gz 43c47239a14e63b69e9df0030cb0f87e 1022449659 obj /usr/share/doc/gpm-1.19.6/TODO.gz 2503b6a66c85bb1d7a2e181ee0a1e927 1022449659 obj /usr/share/doc/gpm-1.19.6/COPYING.gz 25210f5ece93913ba108c385ee072d0c 1022449659 obj /usr/share/doc/gpm-1.19.6/Changes.gz 52c8dda876abcfc30862a79d9b7c55f6 1022449659 obj /usr/share/doc/gpm-1.19.6/ChangeLog.gz 262a889f52a2547e0216b132d4aba1f7 1022449659 obj /usr/share/doc/gpm-1.19.6/MANIFEST.gz b5b28da501099f8862a7357c60d43e67 1022449659 obj /usr/share/doc/gpm-1.19.6/README.gz 93d58337c32f1410d5c68ad68e043c38 1022449659 obj /usr/share/doc/gpm-1.19.6/FAQ.gz c1ca5d9cd27118fda14f9b0ba146a6dd 1022449659 obj /usr/share/doc/gpm-1.19.6/Announce.gz 9931fb514faea41a0ce0927373f4bcb6 1022449659 obj /usr/share/doc/gpm-1.19.6/README.gunze.gz a2099092d4fd5af43ea0140dad7f9fcf 1022449659 obj /usr/share/doc/gpm-1.19.6/README.microtouch.gz b677acfdf2c21cd6848ae36ed63c9407 1022449659 obj /usr/share/doc/gpm-1.19.6/README.synaptics.gz 848e3d254b675f76d6bf6292bf9dcf44 1022449659 obj /usr/share/doc/gpm-1.19.6/README.twiddler.gz 47ee0d51351d0b026da557f9abde5dd0 1022449659 dir /etc dir /etc/gpm dir /etc/init.d dir /etc/conf.d sym /usr/lib/libgpm.so -> libgpm.so.1.18.0 1022449659 sym /usr/lib/libgpm.so.1 -> libgpm.so.1.18.0 1022449659 ----------------------------------snip---------------------------------- No ._cfg there. Just as a side note: maybe I am confused, but why (if it actually worked), do we record the ._cfg, and not the real file ? Point is, in say two weeks when the user wanted to check from what package the file is, he wont remember that it was merged as a ._cfg because of CONFIG_PROTECT ... thus creating some confusion. I can understand that some people would like to know what files was backed up via CONFIG_PROTECT, but could we not handle this then some what differently? For instance record the real file in CONTENTS, and record all ._cfg files in say CPROTECT (or what ever) for instance ? The method that is theoretically in use currently, just do not seem very consistant.
OK, looking at the new config protect code, this is correct behavior as far as I can see. Here's the key to understanding it: we do these things so that merge and unmerge work correctly and don't mess up config files. Now, from an "epm -qf" perspective this doesn't make much sense, I agree. But the CONTENTS files are mainly there so that merge/unmerge work correctly and not so that users can search for files. I do agree that it would be nice if we had a CONTENTS or some other file that contained useful information for the user, but our main goal is to just record info that we need to merge/unmerge. In your case with gpm, what I think is happening is that the emerge code is being very smart. It realizes that the version of /etc/init.d/gpm that it was *going* to install had already been installed in the past, and you modified it. If it installed its own ._cfg0000_gpm file, it would just be throwing a file at you that contains changes that you have already seen and accounted for. Since you have already seen this file in the past, Portage decides not to create any file on disk, because all data indicates that it would be redundant information for you. It has sent this information to you recently, so there's no need to send it again.
