public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] Re: [gentoo-user] How to get rid of Apache2
       [not found] ` <20030526172633.GA28184@cherenkov.orbis-terrarum.net>
@ 2003-05-26 22:18   ` Dhruba Bandopadhyay
  2003-05-26 22:49     ` Dhruba Bandopadhyay
  2003-05-27  0:01     ` Robin H.Johnson
  0 siblings, 2 replies; 3+ messages in thread
From: Dhruba Bandopadhyay @ 2003-05-26 22:18 UTC (permalink / raw
  To: gentoo-user; +Cc: gentoo-dev

CC: gentoo-dev for raising documentation and consistency issues
Subject: Apache2 with mod_php

<quote who="Robin H.Johnson">
> On Mon, May 26, 2003 at 05:56:33PM +0100, Dhruba Bandopadhyay wrote:
>> I emerged apache and being on ~x86 it got apache2.  Now since there
>> was no way in hell it was ever going to work with php for me I removed
>> it.
> Something is wrong here. I maintain PHP, and my primary testing is done
> on Apache2. I've been using Apache2 and PHP together on production
> servers since before I started using Gentoo quite successfully.
>
> Could you please file a bug about what doesn't work for you.

Hello

I have been driven to utter frustration by this issue as everyone claims
to have apache2 and mod_php working but no one tells me how.  :(

robbat2, I initially emailed on gentoo-dev
(http://marc.theaimsgroup.com/?l=gentoo-dev&m=105362815721103&w=2) posing
this very question and got this reply
(http://marc.theaimsgroup.com/?l=gentoo-dev&m=105362905522592&w=2) which I
obeyed but to no avail.  I have also looked unsuccessfully many times on
#gentoo for apache and php devs.

Here's the scenario.  If after reading you still feel I should file a bug
then I'll do so.  There are two issues at hand here.  Firstly, there's an
inconsistency with versioning.  Imagine a freshly installed gentoo desktop
(not server) system without apache installed.  The system has ~x86 set but
not apache2 since the user does not wish to use apache2.  He (or she) then
proceeds to 'emerge apache mod_php'.  Now bearing in mind that the apache2
use flag is *not* set this now emerges apache2 but then proceeds to
compile mod_php *without* apache2 support.  Doesn't this seem like a
complete contradiction?

(-) I suggest policy be rethought on this matter and that consistency be
achieved so that mod_php is compiled with support for the version of
apache that it is intended to accompany.

(-) Should apache2 really be installed as default on ~x86 given the number
of problems that myself and other users on forums have suffered,
especially, when the apache2 flag is unset?  I realise that use flags do
not determine package installation but only optional support but this is
to provide some food for thought.

The second issue here is about what went wrong.  On machine 1, my desktop,
apache1 was already installed and when I moved to ~x86, apache2 was
automatically emerged during updates.  So I recompiled mod_php with
support for apache2.  I ran the ebuild /var/db/... config commands and
restarted apache2 but got some errors.  I tried a few modifications but
once again got some other errors.  I don't have the errors to hand anymore
but can try to reproduce sometime if you wish.  On machine 2, apache had
never been installed and so I added apache2 to use flags and emerged
apache2 and mod_php.  Then following instructions I ran:

$ ebuild /var/db/pkg/dev-php/mod_php-4.3.1-r3/mod_php-4.3.1-r3.ebuild config

and got:
/usr/sbin/ebuild.sh: line 88: //usr/sbin/apacheaddmod: No such file or
directory

Incidentally, I have just tried to emerge mod_php again and got:
----
$ emerge mod_php
Calculating dependencies ...done!
>>> emerge (1 of 1) dev-php/mod_php-4.3.1-r3 to /
>>> md5 src_uri ;-) php-4.3.1.tar.bz2
>>> Unpacking source...
 * This ebuild is intended for ~x86 testing presently. Heavy testing welcome.
 * It should be stable for nearly systems.
>>> Unpacking php-4.3.1.tar.bz2 to /var/tmp/portage/mod_php-4.3.1-r3/work
 * Applying fix for PEAR world writable files                            
[ ok ]
 * Cannot find $EPATCH_SOURCE!  Value for $EPATCH_SOURCE is:
 *
 *   /usr/portage/distfiles/php-4.3.1-db4.diff.gz
!!! ERROR: dev-php/mod_php-4.3.1-r3 failed.
!!! Function epatch, Line 181, Exitcode 0
!!! Cannot find $EPATCH_SOURCE!
----

I would really appreciate some official documentation on how to get
apache2 working with mod_php and mod_ssl and also the subtle differences
between apache1&2.  Following the current desktop configuration guide and
ebuild postinst works for apache1 but not for 2.  I'd also be curious to
hear your thoughts about the versioning issues.

With regards
Dhruba Bandopadhyay



--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [gentoo-dev] Re: [gentoo-user] How to get rid of Apache2
  2003-05-26 22:18   ` [gentoo-dev] Re: [gentoo-user] How to get rid of Apache2 Dhruba Bandopadhyay
@ 2003-05-26 22:49     ` Dhruba Bandopadhyay
  2003-05-27  0:01     ` Robin H.Johnson
  1 sibling, 0 replies; 3+ messages in thread
From: Dhruba Bandopadhyay @ 2003-05-26 22:49 UTC (permalink / raw
  To: gentoo-user; +Cc: gentoo-dev

On Mon, 2003-05-26 at 23:18, Dhruba Bandopadhyay wrote:
> (-) Should apache2 really be installed as default on ~x86 given the number
> of problems that myself and other users on forums have suffered,
> especially, when the apache2 flag is unset?  I realise that use flags do
> not determine package installation but only optional support but this is
> to provide some food for thought.

Further to my last email I'd like to add the following.

(-) At the moment, apache and apache2 are under the same package name
apache.  Perhaps, this should be modified to be two packages slotted
differently?  This would provide the following benefits.

-- It will provide the criterion of choice without ambiguity for
something as critical as a webserver and will not deceptively put a
certain version on when the user is expecting another.

-- It will remove the need to inject a stub for apache2 when using
apache1 as I had to do.  Injecting of stubs really should not be
necessary under normal circumstances on ~x86 unless using hardmasked
packages.

-- It will prevent apache2 being recompiled and installed when executing
emerge -e world when in fact the user wishes to use apache1 which has
happened to me.

Once again, your thoughts are welcome.  I'm not promoting this as a
course of action but merely wish for the best resolution to be
achieved.  The current state of affairs is inoptimal to say the least as
illustrated by this email and my previous one with same subject.

With regards
Dhruba Bandopadhyay


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [gentoo-dev] Re: [gentoo-user] How to get rid of Apache2
  2003-05-26 22:18   ` [gentoo-dev] Re: [gentoo-user] How to get rid of Apache2 Dhruba Bandopadhyay
  2003-05-26 22:49     ` Dhruba Bandopadhyay
@ 2003-05-27  0:01     ` Robin H.Johnson
  1 sibling, 0 replies; 3+ messages in thread
From: Robin H.Johnson @ 2003-05-27  0:01 UTC (permalink / raw
  To: gentoo-user; +Cc: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 6007 bytes --]

(This is a reply to both of your emails)

On Mon, May 26, 2003 at 11:18:48PM +0100, Dhruba Bandopadhyay wrote:
> robbat2, I initially emailed on gentoo-dev
> (http://marc.theaimsgroup.com/?l=gentoo-dev&m=105362815721103&w=2) posing
> this very question and got this reply
> (http://marc.theaimsgroup.com/?l=gentoo-dev&m=105362905522592&w=2) which I
> obeyed but to no avail. 
A further reply to that would have helped resolve issues at the time.

> I have also looked unsuccessfully many times on #gentoo for apache and
> php devs.
I'm in contact-able in #gentoo-dev on average 12 hours out of every day.
A /query or /msg will reach me fine.
Even mailing me directly or posting a bug to BugZilla would get you a
response usually inside 2 days from myself.

> Here's the scenario.  If after reading you still feel I should file a bug
> then I'll do so.  There are two issues at hand here.  Firstly, there's an
> inconsistency with versioning.  Imagine a freshly installed gentoo desktop
> (not server) system without apache installed.  The system has ~x86 set but
> not apache2 since the user does not wish to use apache2.  He (or she) then
> proceeds to 'emerge apache mod_php'.  Now bearing in mind that the apache2
> use flag is *not* set this now emerges apache2 but then proceeds to
> compile mod_php *without* apache2 support.  Doesn't this seem like a
> complete contradiction?
I see little reason to run Apache1 anymore myself. Everything I require
is supported by Apache2. What good reasons do you have for running
Apache1 on ~x86?

mod_mp3 is one of the few I am aware of that doesn't presently support
Apache2, and that is mostly because very little work is primarily
because it is a fairly dead application presently (the mailing list has
had exactly 2 messages this entire month to date).

>> (-) At the moment, apache and apache2 are under the same package name
>> apache.  Perhaps, this should be modified to be two packages slotted
>> differently?  This would provide the following benefits.
>> -- It will provide the criterion of choice without ambiguity for
>> something as critical as a webserver and will not deceptively put a
>> certain version on when the user is expecting another.
'emerge -p' should be run before any operation to check what version of
something you are getting. Anybody that doesn't do this, be it a
production box or a development box, shouldn't expect any sympathy when
their system doesn't do exactly what they expect. 

>> -- It will remove the need to inject a stub for apache2 when using
>> apache1 as I had to do.  Injecting of stubs really should not be
>> necessary under normal circumstances on ~x86 unless using hardmasked
>> packages.
>> -- It will prevent apache2 being recompiled and installed when executing
>> emerge -e world when in fact the user wishes to use apache1 which has
>> happened to me.
As a better workaround than injecting a stub, I would make one
suggestion. Find and emerge some module that doesn't work on Apache2
yet, and so contains a RDEPEND on the lines of '=net-www/apache-1*'. That
will prevent portage from upgrading Apache. (Make sure apache2 isn't set
in your use flags as well). Alternatively, just create some local ebuild
for yourself that does nothing, except holds apache back at v1.

>> Once again, your thoughts are welcome.  I'm not promoting this as a
>> course of action but merely wish for the best resolution to be
>> achieved.  The current state of affairs is inoptimal to say the least as
>> illustrated by this email and my previous one with same subject.
I would agree that the current state of the Apache2 install is
suboptimal for the corner case of those specifically wanting to install
Apache1 on ~x86. How common is this case? From what I have seen, very
infrequent.

> (-) Should apache2 really be installed as default on ~x86 given the number
> of problems that myself and other users on forums have suffered,
> especially, when the apache2 flag is unset?  I realise that use flags do
> not determine package installation but only optional support but this is
> to provide some food for thought.
The great majority of users have experienced no issues AFAIK.

> The second issue here is about what went wrong.  On machine 1, my desktop,
[snip]
> apache2 and mod_php.  Then following instructions I ran:
> $ ebuild /var/db/pkg/dev-php/mod_php-4.3.1-r3/mod_php-4.3.1-r3.ebuild config
> /usr/sbin/ebuild.sh: line 88: //usr/sbin/apacheaddmod: No such file or
> directory
You did not read the postinst instructions then. It says NOTHING about
running the config stage for apache2. The postinst stage provides other
instructions for Apache2.

> Incidentally, I have just tried to emerge mod_php again and got:
> ----
[snip]
> ----
I apologize for this slight glitch. I added a small patch to the PHP
eclass for DB4 support, uploaded it so it would go on the mirrors, and
forgot it in SRC_URI. This has been remedied now. An item like this
would have come to my attention sooner if somebody had filed a bug about
it.

> I would really appreciate some official documentation on how to get
> apache2 working with mod_php and mod_ssl and also the subtle differences
> between apache1&2. 
After installing, adding '-D PHP -D SSL' to your /etc/conf.d/apache2
should be the majority of the setup. (Aside from some SSL stuff, which
I am not certain about, as I don't use it myself).

> Following the current desktop configuration guide and ebuild postinst
> works for apache1 but not for 2. 
The mod_php pkg_postinst specifically lists adding '-D PHP', which I
admit the documentation doesn't describe, but I believe the
documentation is meant for the stable tree at this time.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-05-27  0:01 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <1053968193.3268.3.camel@wolf.codewordt.co.uk>
     [not found] ` <20030526172633.GA28184@cherenkov.orbis-terrarum.net>
2003-05-26 22:18   ` [gentoo-dev] Re: [gentoo-user] How to get rid of Apache2 Dhruba Bandopadhyay
2003-05-26 22:49     ` Dhruba Bandopadhyay
2003-05-27  0:01     ` Robin H.Johnson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox