Re: [gentoo-dev] Re: [gentoo-user] How to get rid of Apache2

[Robin H.Johnson]

(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@××××××××××××××.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