Config files

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?

Tim

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 4/9/07, Tim Jackson <liststimj.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

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php