Hello,
php4-pear package provides some PEAR classes:
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
Mail 1.1.3 stable
Net_SMTP 1.2.6 stable
Net_Socket 1.0.1 stable
PEAR 1.3.2 stable
XML_Parser 1.0.1 stable
XML_RPC 1.1.0 stable
When somebody needs to update any class from above set he can run (for example):
pear update DB
then, pear list shows following set of classes:
blabluga:~# pear list
INSTALLED PACKAGES:
===================
PACKAGE VERSION STATE
[...]
DB 1.7.6 stable
Then, php4-pear package could be upgraded or just reinstalled. Well,
let's run:
apt-get install --reinstall php4-pear
then
pear list
INSTALLED PACKAGES:
===================
PACKAGE VERSION STATE
[...]
DB 1.6.2 stable
DB class has been downgraded without any warning.
Let's look into another case. Pear classes could have a (versioned)
dependecies. For example, XML_Serializer requires XML_Util >= 1.1.1 and
XML_Parser >=1.2.1. php4-pear package contains XML_Parser 1.0.1.
I upgarde XML_Parser to the current stable (1.2.6 when I am submitting
this report), then install XML_Util and XML_Serializer. Great.
Let's check a list of installed packages:
blabluga:~# pear list | grep XML
XML_Parser 1.2.6 stable
XML_RPC 1.1.0 stable
XML_Serializer 0.15.0 beta
XML_Util 1.1.1 stable
Again, php4-pear in reinstalled (security upgrade in stable probably
will do the mess too).
I run apt-get install --reinstall php4-pear
then:
blabluga:~# pear list | grep XML
XML_Parser 1.0.1 stable
XML_RPC 1.1.0 stable
XML_Serializer 0.15.0 beta
XML_Util 1.1.1 stable
XML_Parser class has been quietly downgraded. It could lead to some
unexpected behavior like: http://pear.php.net/bugs/bug.php?id=3448
There is an ugly workaround like putting
DPkg::Post-Invoke {"/usr/bin/pear upgrade-all";};
somewhere in apt.conf.d but it has an obvious drawback - it's run always,
regardless of installed/upgraded packages.
Additionaly, all classes fetched by pear install/upgrade are placed
somewhere in /usr/share. Debian Policy says that site specific programs should
be installed in /usr/local.
The last problem is a good reason to file this bug as a serious one, but
I left the severity readjustment to you.
Regards
Artur
Artur R. Czechowski wrote: Actually, this is the same bug as the first part, since if PEAR was behaving, it would have the base classes it ships in /usr/share, and anything freshly installed/upgraded in /usr/local, have /usr/local first in the include path, and you'd never have this overwriting issue. As it stands, however, it's far too late to fix this for Sarge (we release in a week or so), and people will just have to deal. There are several proposals on the table to fix this for Etch, but I have yet to see any code for it that isn't really scary. Hopefully we'll get it sorted out, though. ... Adam
Hello After stumbling over the same bug I would proposed to simply set the defaults in /etc/pear/pear.conf to /usr/local/ dirs. I did this for my server with "pear config-set" and it seems to work. Mixing Debian packages and pear installed libraries quickly turns into a mess if the directories are not clearly separated! bye,
Hello, I fully agree with this proposal however the main problem is that pear can't deal with two directories and it breaks some webapps setup (for example, function get_installed_pear_packages() in eGroupWare could be broken). See my old post: http://lists.alioth.debian.org/pipermail/pkg-php-maint/2007-September/003106.html Regards,
After looking around for an answer about downloading new pear packages into /usr/local/share and using pear debian package to be sure things are distinct and because I tend to prefer to have manually installed things into /usr/local... I have found this bug which to discuss this problem. What is the status ? Is there a good practice about these problems ? Regards,
How can this be a problem of upstream, since the Debian packagers can change the path as suggested in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443524#21 ? I'm not sure I understand your reasoning here. Care to elaborate more ? Thanks in advance. Best regards,
Then shouldn't the packaging for these apps be fixed so that they depend from the right place where these PEAR libs would belong depending if they are packaged already or not ? I think you may not expect that manually installed web apps can run on a Debian system unchanged if they depend on a mix of packaged and non-packaged PEAR dependencies. In any case, this looks like a PHP policy that may need more debating than this just one bug ? My 2 cents,
It's not that easy. PEAR doesn't have support for multiple directories, so if you change the *_dir to /usr/local/share/php/.. then you have basically lost all packages installed in /usr/share/php. # pear config-show | grep _dir | grep share/php PEAR documentation directory doc_dir /usr/share/php/doc PEAR directory php_dir /usr/share/php PEAR configuration file cfg_dir /usr/share/php/cfg PEAR data directory data_dir /usr/share/php/data PEAR test directory test_dir /usr/share/php/test PEAR www files directory www_dir /usr/share/php/htdocs # pear list Installed packages, channel pear.php.net: ========================================= Package Version State Archive_Tar 1.3.7 stable Console_Getopt 1.2.3 stable PEAR 1.9.1 stable Structures_Graph 1.0.3 stable XML_Util 1.2.1 stable # pear config-set doc_dir /usr/local/share/php/doc # pear config-set php_dir /usr/local/share/php # pear config-set cfg_dir /usr/local/share/php/cfg # pear config-set data_dir /usr/local/share/php/data # pear config-set test_dir /usr/local/share/php/test # pear config-set www_dir /usr/local/share/php/htdocs [...] # pear list (no packages installed from channel pear.php.net) # apt-get install php-net-ping # pear list (no packages installed from channel pear.php.net) On Fri, Mar 18, 2011 at 14:11, Olivier Berger <olivier.berger@it-sudparis.eu> wrote:
IMHO, the way to fix it, is to do these missing Debian packages. Hacking a PEAR Debian package is quite easy, if you only care that it works and if you don't look into having uploaded to Debian! Hacking with 2 PEAR directory will only lead with loads of issues, like one PEAR library depending on another and not being able to find it where it is expected... Thomas
hi guys, i think ideally, yes, but... if we provide pear/pecl commands for the local admin (which i hope nobody argues we shouldn't), they should (a) work, and (b) not clobber/collide with the packaging namespace. so i think that kinda requires that we do have seperate directories. i don't think this is impossible to fix, most other languages packaged in debian work this way... just nobody has cared enough to roll up their sleeves and get it to work right with php (and maybe to figure out what "right" is in the process, since we don't have this defined currently) sean
----- Original message ----- As much as I know, "pear install X" does install a PEAR package named X and does work in Debian. Also, we do package the .reg files in our PEAR packages, so the pear utility see them installed... I don't think we have any issue here... Thomas
We have a issue... apt-get install php-pear/stable pear upgrade apt-get -f install php-pear/stable-security would create pile of mess in /usr/share/php User installed pear modules have to go into some other directory - /usr/local/share/php f.e. O.
----- Original message ----- Running "pear upgrade" (without argument) has never work well in Debian. While it would be cool if it worked, it isn't a regression. Thomas
2011/3/18 Thomas Goirand <thomas@goirand.fr>: Nobody says it's a regression ;-), it just needs fixing so it works. Ondrej
----- Original message ----- Fantastic then! Thomas
-- Good day, I pray that this mail meets you well. Though we have not met or seen each other in person before,If you need a friend,contact me back
-- We got your recommendation from a customer and we would like to place some orders which is needed urgently. Kindly contact me back - Your FOB Prices and FOB Port of loading.- Your estimated delivery time. - Your Mode of Payment. ( If by L/C or T/T ) Cui Lang National Sales Manager +885 (0)12 336 250 |+885 (0) 12 336 251 | +885 (0) 81 336 251. amijikg@outlook.com amijikg@gmail.com
..............-- I know that we are just knowing each other for the first time but we can share ideas,lets be friends I'm expecting your reply .