Bug 723410

Summary: imp won't function without php dom
Product: [Fedora] Fedora Reporter: Joseph D. Wagner <joe>
Component: impAssignee: Jason Tibbitts <j>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 15CC: j, nb
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-21 14:35:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Results of phpinfo() none

Description Joseph D. Wagner 2011-07-20 04:24:12 UTC 
XML and DOM is listed as a REQUIRED prerequisite of imp under 2-2 at:
http://www.horde.org/apps/horde/docs/INSTALL#prerequisites

However, php was build with configure switch '--disable-dom' which directly contradicts imp docs.

Right now, I don't know of a workaround available through RedHat packages.  If none is available, then either 1) php should be rebuild without the '--disable-dom' switch, or 2) imp should be dropped from the available packages because I see no reason to carry a package that isn't fully supported.
Comment 1 Jason Tibbitts 2011-07-20 14:35:39 UTC 
I'm not sure I understand; the XML and DOM components of PHP have been part of the php-xml package for as long as I can remember (git blame says 2006) and the horde package has a hard dependency on php-xml.

I will admit to being a terrible maintainer and not having tested the horde stack on a released F15 (only the pre-F15 rawhide) but it did work fine for me then and it doesn't appear that the base PHP package has changed significantly since then.
Comment 2 Joseph D. Wagner 2011-07-20 15:52:08 UTC 
Well, something is definitely wrong, because http://127.0.0.1/horde/test.php says that DOM isn't there, and components are failing with errors about DOM.

It may not be your fault, per se.  The PHP guys may have changed something.  However, it is impacting your package, so I filed the report here.
Comment 3 Jason Tibbitts 2011-07-20 16:08:09 UTC 
This may be an exceedingly dumb question, but do you realize that you need to restart the web server after installing dynamically loadable PHP modules before they're actually available to running applications?

And what does phpinfo() say?
Comment 4 Joseph D. Wagner 2011-07-21 00:16:40 UTC 
Created attachment 514093 [details]
Results of phpinfo()
Comment 5 Joseph D. Wagner 2011-07-21 00:25:48 UTC 
I double-checked to be sure.  Restarting httpd had no effect.

Now I think it's my turn for a dumb question.  I just tried switching over from worker to the prefork model.  It seems to have fixed my problem.  Is there something in DOM that conflicts with the worker model?  I'm just surprised that everything else worked except that while using worker.
Comment 6 Jason Tibbitts 2011-07-21 14:35:12 UTC 
Unfortunately I do not know the answer to that question; the interactions between PHP internals and Apache internals are not something I'm familiar with.  I can say that I've not seen any issues of that nature before.

I would suggest opening a ticket against php if you'd like to pursue this further.  I'll tack a mention of the issue into the package documentation.
Comment 7 Jason Tibbitts 2011-07-21 18:06:46 UTC 
What I got from a PHP expert is that all of the PHP extensions are only built for (and hence will only work with) the forking model.

The issue has something to do with thread safety.  In any case, this certainly isn't a horde or imp bug.
Comment 8 Jason Tibbitts 2011-07-21 18:10:55 UTC 
And, to be trebly sure, this is in the PHP FAQ:

http://fr2.php.net/manual/en/faq.installation.php#faq.installation.apache2