Re: Re: Question wrt dual-PEAR

Pierre Habouzit wrote:

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 best thing about the way that the local disconnected repository would work is that upgrade-all would *not* touch the debian repository.

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 ...)

You should also look at how gentoo does its ebuilds for pear packages. The --nodeps option is your friend. All you need to do is tell PEAR to ignore all dependencies in package.xml, and make damn sure that dpkg handles them properly (pear makedebian would do this part), and then you can avoid the problem. One other point to consider: PEAR makes use of environment variables. Why not provide a value in /etc/profile for PHP_PEAR_SYSCONF_DIR that points to /usr/share/local? Then, put a pear.conf there that loads the local packages only. This way, the user CAN'T upgrade /usr/dont_touch_this_pear without explicitly choosing the hidden pear.conf that is in /etc (or wherever you put it) that dpkg would use with "pear -c /etc/pear.conf blahblah". This way, the user configuration file would not be affected if root sets one up. Those who play nice and use dpkg would be able to upgrade the system-wide PEAR packages. Those who wish to install newer packages can use the pear command with impunity. It should also be noted that if you choose this option, you can provide a default include_path that is .:/usr/share/local/php:/usr/dont_touch_this_pear so that packages installed using the pear command would work right out of the box for the lazy root. Greg