Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58055
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
Received-SPF: pass (google.com: domain of kris.craig@gmail.com designates 10.216.132.94 as permitted sender) client-ip=10.216.132.94;
MIME-Version: 1.0
In-Reply-To: <4F481E93.1090400@oracle.com>
References: <CAKOpQSwMkn=0cQh9cupj-8qihVvhEEOY-kqQ0F4pLb4J1MfuZA@mail.gmail.com>
	<a0f321a49cb0932bde8bba4adc890bca.squirrel@www.l-i-e.com>
	<CAKOpQSwYa89n3s8FzytQ49i8MqUA9sFsQRh+enGzADg=h4A4xg@mail.gmail.com>
	<4F481E93.1090400@oracle.com>
Date: Fri, 24 Feb 2012 15:54:40 -0800
Message-ID: <CAKOpQSzRdjqThrTb6JeEzhnKmg_85WKejicN1rhMp49+v6cjHg@mail.gmail.com>
To: Christopher Jones <christopher.jones@oracle.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016e6da7d64e2ffb804b9be7b05
Subject: Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure
From: kris.craig@gmail.com (Kris Craig)

--0016e6da7d64e2ffb804b9be7b05
Content-Type: text/plain; charset=ISO-8859-1

Yeah since we pretty much rely on APXS to do the httpd.conf stuff, we're
really limited in terms of what we can do.  That is, unless we want to
start manually doing this in the configure script in lieu of APXS, though
I'm not sure that would be worth the trouble and the overhead.

LoadModule clashes still happen in the current releases.  I haven't tested
it on 5.5-dev but it definitely exists on 5.3.x.  I have yet to test it on
5.4 but I'm not aware of any changes there that would've affected this.  So
this is an existing problem, though admittedly it's really just more of an
unnecessary annoyance.  If you're doing QA work or something else that
involves frequent PHP rebuilds and you have your PHP configuration in a
separate .conf file (as is good practice anyway), this tends to become
quite irritating.  And since APXS already has the solution built-in, it
seems kinda silly not to make use of it.

The open question of course won't be in the RFC when voting begins.
However, I have yet to hear from one single person on that question.  I'll
make an arbitrary decision on that if nobody cares, but I want to give
everyone an opportunity to weigh-in on that question.  At very least, could
somebody tell me if we're still supporting Apache 1.3.x or not?  If we are,
any idea if/when we're planning on phasing that out?  I'd feel a lot better
if I at least knew where we stood on that.

I'll look into the comma separation suggestion and see if that'll work.
Mainly I just want to make sure we're not breaking any existing
functionality; i.e. I want people to be able to not specify this at all and
still get the same behavior they did before this change.


--Kris


On Fri, Feb 24, 2012 at 3:34 PM, Christopher Jones <
christopher.jones@oracle.com> wrote:

>
>
> On 02/24/2012 02:38 PM, Kris Craig wrote:
>
>> Thanks for the input!  You're right, I'll go ahead and clarify that in the
>> RFC.
>>
>> I'll probably initiate voting on Monday unless something changes between
>> now and then.
>>
>> --Kris
>>
>
> The real issue with the PHP install is that it doesn't add "AddType"
> or "SetHandler" to update httpd.conf.  Basic users relying on .php
> file extensions have to manually edit the file.  It would have been
> friendly to make the default install "just work" for these people.
> Experienced developers will want to make their own changes regardless
> of what the base install does.
>
> Easier said than done, but that makes it a good project.
>
>
> --
> Email: christopher.jones@oracle.com
> Tel:  +1 650 506 8630
> Blog:  http://blogs.oracle.com/opal/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0016e6da7d64e2ffb804b9be7b05--