Description: ------------ As discussed in pear-dev a while ago (http://marc.info/?l=pear-dev&m=117614529228378) PEAR should have a role="cfg". role="data" doesn't cut it because 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. A first-case simple implementation of this would, on upgrading a file with role=cfg, check the md5sum (or similar) of the existing file, and if it differs from the new file issue some kind of warning, and write the new file to a different location (e.g. file.cfgnew or something).

This would be kind of nice to go in 1.7.0 alongside www_dir...

I had a brief look into this the other day and I couldn't figure out whether or not this can be done given the current interface to Role_Common. I'm not sure whether setup() gives enough flexibility. The four key challenges I see are: a) see if we are doing a fresh install, or upgrade b) get filename of existing file if upgrade; calculate MD5 sum c) get filename of file "about to be installed"; calculate MD5 sum d) dynamically change final destination path of file to be installed dependent on results of (b) and (c)

this is easy to implement. Basically, our goal is to avoid overwriting a configuration file in the same location. Therefore, we use processInstallation() inside setup() to retrieve the location that this file would be installed. Then, see if a file exists there. If so, compare the md5sum, and if they're different, install the file appending .new-version (i.e. for package version 1.2.3 and configuration file /path/to/cfg/my.cfg, it would install /path/to/cfg/my.cfg.new-1.2.3) 20 lines of code or so and it is implemented. The only question is what should be the default location of cfg_dir?

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. scratch that - I'll just use /cfg by default like we use /data for data_dir.

Thanks for doing that Greg! Fantastic. Only point I would make is I'm not sure about the need for the version suffix for newly-installed files. If you have a (modified) config file foo.cfg, then you update to v 1.1.2, you then get foo.cfg-1.1.2. Upgrade again to 1.1.3 and you now have foo.cfg-1.1.3 as well; at this point, you're really not interested in foo.cfg-1.1.2, because that's an unmodified default from a version you no longer have installed. That's why in RPM land we just use ".rpmnew" and leave it at that.

have you tried it? foo.cfg-1.1.2 should be erased on upgrade, leaving only foo.cfg-1.1.3. If not, that's a boog to feex

I updated the unit test to verify that indeed foo.cfg.new-1.4.2 is erased on upgrade.