Re: Advice needed: best installation strategy with CVS

Hi Al, I've been thinking about issues related to this for a while, and have come to the conclusion that in a situation where you are going to need to move an application to more than one location that uses PEAR, you should seriously consider using the best strengths of PEAR. In other words, instead of bundling PEAR modules in CVS, why not create a package.xml for your project, with specific dependency. <dep type="pkg" rel="eq" version="1.4.0">MDB</dep> rel of eq tells the installer to ONLY install version 1.4.0, and no other version is an option. In addition, if you specify specific command-line options (try pear help options), you can set up a unique PEAR installation for that application alone. For instance. Let's say your app depends on DB and DB_DataObjects. You have some code that is used on the global website which uses DB 1.6. Your application depends on an earlier version of DB, and is untested with anything above DB 1.4. What you can do is twofold. On the initial install to the production server, run pear with a lengthy command-line. You need to specify -php_dir: where the PEAR executable (.php) files go -data_dir: where data stuff goes -test_dir: where tests go -doc_dir: where docs go In addition, the first run must specify a location for the configuration to be saved. $ pear -c /usr/local/myapp/.pearrc -d "php_dir=/usr/local/myapp/pear/lib" -d "data_dir=/usr/local/myapp/pear/data" -d "test_dir=/usr/local/myapp/pear/test" -d "doc_dir=/usr/local/myapp/pear/docs" -s config-show This command-line basically tells PEAR to use /usr/local/myapp/.pearrc for a local configuration, to set all the values, and to save it. In addition, it will show you the values you've set (config-show), so you can correct any typos or omissions. On subsequent runs, you can do: $ pear -c /usr/local/myapp/.pearrc config-show and you'll see the values were saved (hopefully :). At this point, you can simply install the application through a 2-step process: - on the dev server, run: $ pear package from the CVS base directory - upload the .tgz that is created and install it $ pear -c /usr/local/myapp/.pearrc install -a Myapp.tgz The -a option will automatically install all dependencies from pear.php.net (code I wrote, which was added in 1.3b1, so make sure you've upgraded to use it). However, writing this email has brought to my attention a problem with the code - handling of rel="eq" will not attempt to download the correct version automatically, I'll have to open a bug and fix that :). Then, in the future, if you find that you application works with a new version of the packages on the dev server, you can run $ pear -c /usr/local/myapp/.pearrc upgrade DB or $ pear -c /usr/local/myapp/.pearrc upgrade -a Myapp.tgz , for instance. For creation of the package.xml, I would recommend using PEAR_PackageFileManager to create it, as this greatly simplifies error catching and formatting. I am biased, because I wrote that package, but it is used to generate the package.xml for phpDocumentor, one of the largest and most complex. If your application is anything near as complicated, you will want it, particularly for the support of being able to generate a filelist from a CVS checkout. Hope this is helpful, Greg Al wrote:

Hi all, I'm need of some advice about the best strategy for installing PEAR what should be a fairly common environment. We currently have a development server, a staging server and three production servers (all *nix) working from code based in a common CVS repository. We would also like to include the PEAR modules that we use in this repository to ensure PEAR version consistency across all our servers. My current thinking is that I simply need to install all the modules manually, but can see module inter-dependencies causing headaches in the future. I was hoping that the PEAR command-line installer had some way of specifying a directory to install in. Is this possible? Has anyone else operating in a similar environment got any little gems of advice to share? Thanks in advance, Al