Paludis removes config files during upgrade

[robryk]

If an installed package contains an unchanged config file (ie. a protected file) and a new version contains a modified version thereof, paludis first adds a ._cfg... file during merging and then, during unmerging of the old version removes the original file, thus leaving no file in place. If the config file has been changed, it isn't removed due to its modification time, but for some reason config protection checking doesn't seem to work. I am positive that in the vdb directories, in environment.bz2, CONFIG_PROTECT and CONFIG_PROTECT_MASK are set and CONFIG_PROTECT contains /etc.

I don't know whether this appears in newer versions of paludis, but I think this might cause system to be inaccessible (for example, after baselayout or pam update), so users should be warned against it.

[ciaranm]

Where did the original config files come from?

[robryk]

Previous version of package, installed by portage. For example, this happened to my eixrc when updating eix.

[ciaranm]

Hrm, see, I've seen this when using catalyst-generated stages and then reinstalling a package using paludis on top of that -- that's due to catalyst breaking CONFIG_PROTECT. But I've not seen it with Portage-installed packages. Can you come up with an exact sequence of steps to reproduce this?

[robryk]

Portage-generated VDB entry of the previous version of the package

[robryk]

Typescript oshowing a way to reproduce the problem

[robryk]

OK, so the typescript contains a whole reproduction, which generally boils down to:

emerge -1 '=eix-0.9.10'
dispatch-conf
paludis -i eix --dl-upgrade as-needed

The bz2 is of the vdb entry, which I copied before upgrading eix with paludis for the first time (I was already aware of the problem, as I just upgraded baselayout)

[dleverton]

Looks the same as ticket:618. Marking as a dupe since that one's more active.