Re: Re: Question wrt dual-PEAR

MadCoder wrote:

MadCoder wrote:

I'll go in the sources of PEAR package manager and try to see if a sth clean can be make about that problem.

Ok, here we are ... the *main* problem (against the feature I want) is the PEAR_Config class. it is designed to take a local *and* a global conf. but the local settings *override* globals. they do not complete them. So it's a dead end. I've looked at the sources, and incorporate the feature I would like to have (as a debian admin and a debian packager) would mean quite a big design refactor (at least in PEAR 1.3.x). *BUT* I have some kind of idea of a hack, but that *may* be a quick and dirty solution : we may build /usr/local/share/php/.registry/ have a lot of symlinks to /usr/share/php/.registry/*reg files I've tested, at least the installer works correctly. The problem is wrt packages you may want to upgrade. e.g. debian ships atm PEAR 1.3.2. maybe the root wants to have 1.3.4 ... if he does : pear upgrade pear then it will overwrite debian's pear 1.3.2 and not : delete the symlink in /usr/share/local/php/.registry and do a pear install pear. And I believe it will be rather hard to write a wrapper smart enough to avoid such problems. Does anybody has ever tried to maintain such a dual PEAR tree ?

I will consider the possibility of tweaking the way that PEAR_Registry grabs information to see if we can't support the kind of stuff you're talking about. I'm absolutely positive that anything quick and dirty will come back to bite you - hard. Don't go that route. I maintain a dual PEAR tree on my hosting provider. The host has PEAR installed globally, and I have a local copy in my ~. I have simply used a different pear command for checking system and local copies. The main thing was making sure include_path had my local copy in front of the system copy, because the php code that uses PEAR doesn't care where it is installed. I don't actually want to list system and local packages in the same output, that would confuse me to no end. In order to support that idea, it would require a ridiculous amount of modification to commands like pear list, pear upgrade-all, and so on. How would you handle the situation where the local copy is older than the system copy? What about upgrading a package where some of the dependencies are present in the system package but are too new (older copies of the packages would need to be installed locally)? The list of unnecessary complexity this introduces is unsettling. I'm not saying someone won't come along with an elegant solution, just that I have no energy left to do yet another huge overhaul of PEAR that changes things but tries to maintain BC (these changes would break every existing PEAR install, particularly on windows). This would need to be a complete restart of how things work with PEAR 2.0. Your only reliable solution is going to be to write a wrapper script for the pear command that manually passes in -c /etc/pear.conf and modify the /usr/bin/pear wrapper to manually pass in -c /usr/local/pear.conf. Then document heavily that debian PEAR packages MUST be upgraded using the debian package manager, and the user can upgrade local packages with the -c option. FYI, I am inches from releasing PEAR 1.4.0a1, and if you can cobble together makedebian, that would be great. Don't worry about the code for processing package.xml, that's the easy part. All I need are the templates and basic instructions about what must be present in the templates. In addition, I need to know everything there is to know about how debian handles dependencies, so I can map PEAR's dependencies to debian's. Greg Greg