On Fri, 2005-07-15 at 15:31 +0100, Peter Campion-Bye wrote: > Hi, > Apologies if I've misunderstood the use of CONFIG_PROTECT, but I think > I've found a hole in it. As I have lots of stuff under > /var/www/localhost/htdocs which contains configuration files mixed in with > the code ( phpmyadmin, phpldapadmin, phpwiki, squirrelmail, gallery etc ) > I have put the path /var/www/localhost/htdocs into CONFIG_PROTECT in > make.conf. When one of these packages is upgraded this seems to work fine. > Last night, after upgrading PHP to 4.4.0 my wiki was broken. I thought a > good place to start would be to re-emerge phpwiki, so I did. During the > emerge it flashed up a message about this being a package that it couldn't > upgrade, so it would be unmerged it first. It appears that this bypassed > the CONFIG_PROTECT mechanism, as when the new files were installed the > original had been removed, so no ._cfg0000_ files were created for the > changed files. > Having no recent backup (lesson learned!) I had to recreate the phpwiki > config, which is a non-trivial job. > So the question is, how can config files be protected in this kind of > situation (other than backing them up) - is there another mechanism to > protect files from being overwritten, and how many packages are likely to > do an unmerge before re-emerging, and is there ay way of knowing? I > believe the default behaviour on umnerging a package is to leave its > configuration files in place, this doesn't seem to apply to the web apps.
phpwiki I believe uses webapp-config rather than the default ebuild staging method of installing applications. Have you read the documentation to webapp-config? -- gentoo-user@gentoo.org mailing list
