>
> > 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>
|