Re: Summary: dependencies and Applications

Greg Beaver wrote:

OK, here is an attempted summary of the ideas that were ruled at the very least feasible: #1) (Many people)

I think thats a huge over estimate you(its more like 2-3 people at most.) :)

So, I propose this refinement and combination of all ideas:

........CUT.....

-current major versions would remain exactly the same. No need for the little script of #1 -the next major version of a package would be installed to directory PEAR/Package/vX where X is the major version number (PEAR/MDB/v2).

I'm still not conviced that this is necessary it creates more problems than it solves, opens a huge can of worms, and ruins one of the key attractions of pear, that locating source code is directly related to class name.

-internal paths should be calculated using dirname() and __FILE__ (a relative path of the parent directory can be found with dirname(dirname(__FILE__))

this has be discussed many times.. - and the explained many times why it's not a good idea. set_include_path(dirname(__FILE__) . '../;' . get_include_path()); In your application's core 'common.php' file works 100% of the time in PHP4.3 to solve locating files for alternative versions of pear files. (the ini_get/set version works on most hosters.. of older versions) What is being said generally, is that we are going to obiterate pear's clean structure, because a few people are too lazy add the above to their applications..

-the addition of a new command "revert" - if you run a "pear upgrade package", and everything breaks that was working, the "pear revert package" command would revert your upgrade back to the last working install. sounds plausible.. - involves setting up a transaction history in the registry I guess.

its already posible to install older versions using pear --installroot=/my/application install

      http://pear.php.net/get/DB-1.2.tgz

-the addition of a new script pear-app which will handle application installs. This script would use a different installer and process an application.xml file. The application.xml could allow dependencies on both PEAR repositories and other repositories, but these details can be worked out separately from this thread. not sure why the package.xml cant be extended for this.. - there appears to be only a few minor features required..

These changes should make dependencies much more reliable. Greg

-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com