Re: Re: Question wrt dual-PEAR

Greg Beaver wrote: > 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. thanks > I'm absolutely positive that anything quick and dirty will come back to > bite you - hard. Don't go that route. I do agree 2000% > 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 use of the local copy is a pure choice of the user (the root actualy) if he needs to have a copy in /usr/share/local, then *he* has to put it explicitely in the include_path (not debian) In fact, the thing that frightens me the most is if a user uses pear upgrade-all instead of apt-get upgrade. And the other problem is that some (even stable) packages needs packages that are in debian, but too old. and I fear that the interplay between all of them will be a real mess. > 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. I understand you, and my first wish is to find the *best* solution we can, not the first one. > 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. yeah, maybe having two fully disconnected repository isn't such a big pain after all ... I must think at it a little more. > 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. well, maybe it won't be ready for 1.4.0, since there is some majors problems wrt pear in debian : the major one is that php4-pear package : 1. should be named php-pear 2. in fact provides : Installed packages: =================== Package Version State Archive_Tar 1.1 stable Console_Getopt 1.2 stable DB 1.6.2 stable HTTP 1.2.2 stable MDB 1.3.0 stable Mail 1.1.3 stable Net_SMTP 1.2.6 stable Net_Socket 1.0.1 stable PEAR 1.3.4 stable XML_Parser 1.0.1 stable XML_RPC 1.1.0 stable which will : (1) complicate the automatic dependency gestion (that's why my current doc does not consider the deps problem) (2) disallow the user to do sth like : pear makedeb mail dpkg -i php-mail ... because it will conflict with the debian php4-pear package. and this sux (it's cleary our problem not yours, but ...) Moreover, I don't really know how to handle pecl packages elegantly atm. So I guess it's a bit early to have a functionnal ``pear makedeb'' I'll still look at Pear_Command_Package class in order to know how makerpm works ;) -- ·O· Pierre Habouzit ··O OOO http://www.madism.org