On Mon, Mar 08, 2010 at 12:48:00PM -0600, BJ Dierkes wrote:
>
> On Mar 8, 2010, at 12:20 PM, Josh Kayse wrote:
>
>
>> I have recently acquired mod_wsgi commit permissions and am going
>> through some of the open bugs for it on bugzilla. According to
>> [1], and from my testing, mod_wsgi and mod_python conflict
>> resulting in apache segfaulting. The policy currently states that
>> no packages in EPEL may conflict with a package from Red Hat Base.
>> Technically, mod_wsgi and mod_python conflict with each other, but
>> mod_python is optional.
>>
>> I don't think that mod_wsgi should be pulled from EPEL because it
>> is already built for RHEL5 and it is usable as long as mod_python
>> is disabled in apache.
>>
>> [1]
https://bugzilla.redhat.com/show_bug.cgi?id=524120
>>
> I agree, and think there might be room in the policy for edge cases
> like this. I'd like to see something added to the policy that would
> cover this situation, being that mod_python is optional.
>
Maybe anything that can potentially conflict with an optional component
in the base operating environment can be installed, but should be
installed in such a way that it's not enabled by default.
Sysadmin would need to go do something manual to cause breakage on his
system.. (or disable / uninstall mod_python).
Ray
I like this approach better in that it allows an administrator to more
easily switch between the 2 modules. The packages don't conflict from a
file standpoint, only from an operational standpoint. Perhaps an admin
decides to have 2 separate Apache servers setup/configured on his
system, one to run mod_wsgi applications and the other to run mod_python
applications.
The problem is that the sysadmin would need to know to go and configure
mod_wsgi to explicitly turn it on whereas if the packages conflicted
mod_python would need to be removed first.
-josh
--
A: No.
Q: Should I include quotations after my reply?
Don't top post: see