[dev] Fwd: [PEAR-DEV] important new features for application support in upcoming PEAR installer 1.7.0

[Jan Schneider]

Great news:

----- Weitergeleitete Nachricht von greg at chiaraquartet.net -----
      Datum: Mon, 29 Oct 2007 12:34:15 -0500
        Von: Greg Beaver <greg at chiaraquartet.net>
    Betreff: [PEAR-DEV] important new features for application support  
in upcoming PEAR installer 1.7.0
         An: PEAR developer mailinglist <pear-dev at lists.php.net>

Hi all,

In the preparation for the release of Pyrus preview development release
1, I've added two significant new file roles to the PEAR Installer,
which will appear in version 1.7.0, to be released very soon.

The new file roles are "www" and "cfg."

The "www" file role is intended to be used for public web files of a
PEAR package.  This is, for instance, where a web application would
store its public frontend.  This role is intended to obsolete the
Role_Web "web" role available from pearified.com, and to fold this
functionality into the core as an official component.  The web role was
not a part of PEAR originally because of doubts about its utility, but
long usage in production environments such as the backend of
pear.php.net have proved its design to be a good model.  The most major
difference between the "web" role and the "www" role is that the "www"
role does not perform PHP file validation on its contents, which makes
packaging image files and other binary files a possibility.  Also
important is that the "www" role respects the baseinstalldir attribute,
allowing more flexible layout of files in the development environment.

The "cfg" file role is intended to be used for configuration files that
may be customized by the user, or even by the application itself.  As
such, the PEAR installer will never overwrite a configuration file.

For example, let's say a configuration file in package Foo version 1.2.3
is named "config.xml."  The user installs Foo version 1.2.3, resulting
in the configuration file residing in:

/usr/local/lib/php/cfg/Foo/config.xml

The user later upgrades to Foo version 1.3.0, and some changes have been
made to the configuration file.  PEAR will detect these changes, and now
these two files will exist:

/usr/local/lib/php/cfg/Foo/config.xml
/usr/local/lib/php/cfg/Foo/config.xml.new-1.3.0

If the user chooses to ignore the changes made to the configuration
file, and later upgrades to version 1.3.1, the directory will now contain:

/usr/local/lib/php/cfg/Foo/config.xml
/usr/local/lib/php/cfg/Foo/config.xml.new-1.3.1

In other words, outdated configuration files are automatically erased.

Applications can also choose to provide a post-install script that does
merging of configuration files, this is something the PEAR installer
does not control, and leaves up to application authors/users to handle.

I would love feedback on the implementation of these two features, and
will be providing a testing tarball of the PEAR installer shortly for
the normal QA release process.

Greg

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


----- Ende der weitergeleiteten Nachricht -----


Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/