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?
Hey Tim,
Sounds like an excellent idea to me : )
Why wait for PEAR2, perhaps you could already create the role in a
seperate package, similar to pearified.com's Role_Web ?
I'm +1 to do it either way. I've never used config files myself yet, but
having the option would be excellent.
I'll go back to lurking now.
Vladimyr
--
Owner, <a href="http://www.peninsulawebsolutions.com">Peninsula
Web
Solutions</a>