Re: Config files

On 4/9/07, Tim Jackson <lists@timj.co.uk> wrote:

This probably isn't an issue that arises so much when using the PEAR Installer for libraries, but when using it for whole apps it does. I'm kind of thinking that we should have a role="cfg" here. role="data" is OK, but if you install a (working) sample file into its final location (so the app is "ready to use") the files get silently overwritten/removed on upgrades/uninstalls. The only obvious way I can see is to either install the file as a doc and get the user to copy it manually, or do something funky with post-install tasks (which is overcomplicated). Looking at other packaging systems, the need for a "config" role is supported by the fact that RPM has a separate file "role" (or the equivalent) for exactly this situation. Not only that, but it has two variants: replace and noreplace. In the former (less common) case, config files *are* overwritten on upgrade, but are backed up on upgrade or removal of the package (myfile.conf => myfile.conf.rpmsave). In the latter case, which suits most config files, config files are *not* overwritten on package upgrade, but instead the new config file is installed with the ".rpmnew" extension and a warning is issued at install time. Then, the user can (at their leisure) diff the two files and decide what to do (e.g. merge changes from .rpmnew into the main file, or just ignore the new one if nothing needs to be changed). Should I put this on the list for PEAR2?

Sounds like a decent feature to me. I've always liked portage's way of installing with a special filename and using dispatch-conf to update config files. -- Justin Patrin