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?
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 ?
Greetings,
Tias
--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php
|