In /usr/lib/portage/pym/portage/dbapi/vartree.py, dblink.mergeme ignores config protection when merging a new file (lines 2738--2751 in 2.1.6.13). This means that CONFIG_PROTECT does not prevent (initially) identical config files from being hardlinked to each other. This will likely baffle the user when he starts configuring his newly installed package. NOTE: I browsed the 2.2 code and noticed hardlinking is gone. However, 2.2 is still hard masked.
(In reply to comment #0) > In /usr/lib/portage/pym/portage/dbapi/vartree.py, dblink.mergeme ignores config > protection when merging a new file (lines 2738--2751 in 2.1.6.13). Maybe the code is confusing, but the way I read it, hardlinks are not created for protected files in any case. The "protected" variable is always True for protected files, and the "hardlink_candidates" variable is always None when "protected" is True. As a result, hardlinks should never be created for protected files.
Created attachment 196867 [details] "bin" ebuild for hadoop 0.19.1
Then maybe I don't understand how CONFIG_PROTECT works. I wrote a simple "bin" ebuild for apache hadoop which just installs everything to /opt: files "masters" and "slaves" get hard linked together. I'm posting the ebuild as an attachment.
(In reply to comment #3) > Then maybe I don't understand how CONFIG_PROTECT works. I wrote a simple "bin" > ebuild for apache hadoop which just installs everything to /opt: files > "masters" and "slaves" get hard linked together. If "masters" and "slaves" are under /opt, then it's normal for them to get hard linked together, unless you have /opt in your CONFIG_PROTECT. You can check the value like this: portageq envvar CONFIG_PROTECT
They are under /opt/hadoop/conf, which I added to CONFIG_PROTECT (take a look at the ebuild). I'm doing: INSTALL_DIR=/opt/hadoop export CONFIG_PROTECT="${CONFIG_PROTECT} ${INSTALL_DIR}/conf" Before src_install and I'm also adding an env.d file which contains: CONFIG_PROTECT=${INSTALL_DIR}/conf If I run portageq envvar with the package already installed, everything looks fine: $ portageq envvar CONFIG_PROTECT /etc /opt/hadoop/conf For actual config protection this is ok, because there is nothing to protect during a clean install. To avoid hardlinking on first install, however, I need to protect /opt/hadoop/conf inside the ebuild, which I thought I could accomplish with the above export.
Oh, I see. This is related to bug 194043. I suppose that we can make portage parse the env.d entries from $D and use them to modify the CONFIG_PROTECT settings used for installation.
