[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: php4 requires to reinstall all php extensions (mass bugreport)



On Fri, Aug 20, 2004 at 10:35:49AM +0200, Jeroen van Wolffelaar wrote:
> Well, bumping version number doesn't help.
Erm...
> Extensions only change php.inis on upgrade and dpkg-reconfigure,
... you just say that bumping version number _does_ help.

> and php4-cli (or any other newly installed SAPI) doesn't know how to
> trigger reconfigures of all php extensions.
But extensions know (or could know) it itselfs. 
There could be a magic to detect SAPI's, like:
for SAPI in `find /etc/php4/ -type d -maxdepth 1 -mindepth 1 | sed -e's#.*/##'`
or hardcoded values.

In first case uploading package to archive with increased debian revision
would be sufficient. In the second one maintainer should add cli as a valid
SAPI in config/postinst script.

> Adam Conrad, PHP maintainer, says this is a known bug, it's a bug in the
> php4 package and no the extensions (a proper way to deal with this
> should be designed), and it won't be fixed before sarge is released.
Well, I think that Adam is too selfcritical :) I wouldn't call it a bug.
There is rather a lack of policy and tools to maintain dependencies between
webservers, php and php extensions. It just requires some additional work
from extensions' maintainers. Like in this case.

I agree that the lack of policy and tools is not a sufficient reason to hold
a sarge release, but the case I mentioned in my initial mail shall be
considered as one.

> By the way, some extensions simply don't support the CLI SAPI yet at
> all (php4-interbase for example), which is IMHO something that should be
> fixed.
I agree.

> > This problem affects only sarge and sid users - php4 had changed a lot
> > since woody (zendapi,phpapi) and all php4 extensions shall be upgraded to
> > meet dependency requirements.
> This problem _also_ affects woody -> sarge upgrades, upgrading
> extensions simply doesn't solve the problem.
I cannot agree. Due to dependencies order of actions during update will look
like this:
php4 unpacked (creating /etc/php4/apache dir)
php4-cli unpacked (creating /etc/php4/cli dir)
php-extensions unpacked
[...]
php4 set
php4-cli set
php-extensions set (using existing directories in /etc/php4 to detect SAPIs)

What's wrong with this scheme?

> If a mass bug filing highly related to a certain package (php4 in this
> case), cc'ing those maintainers is usually a good idea.
I'll drop the note to them and ask to focus on this thread in private mail.

Cheers
	Artur
-- 
http://www.ralphm.net/world



Reply to: