Re: Advice needed: best installation strategy with CVS

Hi Greg, Thanks very much for this detailed info ... it's certainly pointed me in the right direction. I found your tips on the Pear installer options especially useful. I'm not sure if it's just a reflection of my research skills or simply non-existant documentation, but I was unable to find any references to these while doing a basic search on the Pear site. Thanks again, Al "Greg Beaver" <greg@chiaraquartet.net> wrote in message news:3FA1E786.4040900@chiaraquartet.net... > 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