Opening discussion on RFC pertaining to adding a new option to the
configure script with regard to how/whether APXS touches the httpd.conf
file.
This is my first RFC post so please go easy on me if I screwed-up on
procedure in any way. =)
Here it is: https://wiki.php.net/rfc/apxs-loadmodule
Thanks!
--Kris
Kris Craig kris.craig@gmail.com writes:
Opening discussion on RFC pertaining to adding a new option to the
configure script with regard to how/whether APXS touches the httpd.conf
file.This is my first RFC post so please go easy on me if I screwed-up on
procedure in any way. =)Here it is: https://wiki.php.net/rfc/apxs-loadmodule
Thanks!
--Kris
I, for one, would prefer this behavior to be toggalable at the least,
and preferably to not touch httpd.conf by default.
Hi,
Opening discussion on RFC pertaining to adding a new option to the
configure script with regard to how/whether APXS touches the httpd.conf
file.This is my first RFC post so please go easy on me if I screwed-up on
procedure in any way. =)Here it is: https://wiki.php.net/rfc/apxs-loadmodule
A bit history:
The svn revision r192467 had this comment:
- Changed -a to -A to prevent enabling PHP in httpd.conf automatically.
Most distributions use separate file in a conf.d/ directory to enable
PHP, using -a would add unnecessary line in the main httpd.conf and
causes a warning during startup.
This was reverted in r194843
- Revert -a to -A change, bad idea: It disables EXISTING lines too!
I think we should be careful there.
johannes
@Johannes Agreed. That was one of the reasons I decided to make the
existing behavior (i.e. "-a") the default.
I haven't independently confirmed that issue in APXS but I have heard it
mentioned before; I'll test it myself when I get home just to make sure,
since the APXS docs are a bit vague on this.
Either way, I think so long as our documentation is clear and the existing
behavior is default then it shouldn't pose a problem.
--Kris
2012/2/20 Johannes Schlüter johannes@schlueters.de
Hi,
Opening discussion on RFC pertaining to adding a new option to the
configure script with regard to how/whether APXS touches the httpd.conf
file.This is my first RFC post so please go easy on me if I screwed-up on
procedure in any way. =)Here it is: https://wiki.php.net/rfc/apxs-loadmodule
A bit history:
The svn revision r192467 had this comment:
- Changed -a to -A to prevent enabling PHP in httpd.conf automatically.
Most distributions use separate file in a conf.d/ directory to enable
PHP, using -a would add unnecessary line in the main httpd.conf and
causes a warning during startup.
This was reverted in r194843
- Revert -a to -A change, bad idea: It disables EXISTING lines too!
I think we should be careful there.
johannes
Any further thoughts on this?
--Kris
@Johannes Agreed. That was one of the reasons I decided to make the
existing behavior (i.e. "-a") the default.I haven't independently confirmed that issue in APXS but I have heard it
mentioned before; I'll test it myself when I get home just to make sure,
since the APXS docs are a bit vague on this.Either way, I think so long as our documentation is clear and the existing
behavior is default then it shouldn't pose a problem.--Kris
2012/2/20 Johannes Schlüter johannes@schlueters.de
Hi,
Opening discussion on RFC pertaining to adding a new option to the
configure script with regard to how/whether APXS touches the httpd.conf
file.This is my first RFC post so please go easy on me if I screwed-up on
procedure in any way. =)Here it is: https://wiki.php.net/rfc/apxs-loadmodule
A bit history:
The svn revision r192467 had this comment:
- Changed -a to -A to prevent enabling PHP in httpd.conf automatically.
Most distributions use separate file in a conf.d/ directory to enable
PHP, using -a would add unnecessary line in the main httpd.conf and
causes a warning during startup.
This was reverted in r194843
- Revert -a to -A change, bad idea: It disables EXISTING lines too!
I think we should be careful there.
johannes
Opening discussion on RFC pertaining to adding a new option to the
configure script with regard to how/whether APXS touches the
httpd.conf
file.This is my first RFC post so please go easy on me if I screwed-up on
procedure in any way. =)Here it is: https://wiki.php.net/rfc/apxs-loadmodule
This seems to me like a useful addition, with minimal risk, and many
sysadmins would welcome it.
Has to default to current behavior, of course, which one might want to
add to the RFC explicitly.
+1 until somebody explains why it's "bad" :-)
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
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
Opening discussion on RFC pertaining to adding a new option to the
configure script with regard to how/whether APXS touches the
httpd.conf
file.This is my first RFC post so please go easy on me if I screwed-up on
procedure in any way. =)Here it is: https://wiki.php.net/rfc/apxs-loadmodule
This seems to me like a useful addition, with minimal risk, and many
sysadmins would welcome it.Has to default to current behavior, of course, which one might want to
add to the RFC explicitly.+1 until somebody explains why it's "bad" :-)
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
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/
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:
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/
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,
It doesn't happen for me and I frequently build PHP 5.3, 5.4 and trunk
mods. The library name is the same for all branches. Are you sure
it's not a feature/bug of your APXS version? Anyway, the RFC needs
more investigative description, IMHO.
Chirs
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
No, it happens and it's even clearly documented in APXS.
Basically, if you specify the "-a" option in APXS, it overwrites your
httpd.conf (or apache.conf or whatever it is on your system) and adds the
LoadModule line to it. In PHP's configure script, you'll notice that "-a"
is always specified; there's no option to use APXS without it. As a
result, "make install" will always overwrite your LoadModule entry in
httpd.conf if APXS is enabled. The problem occurs when you have LoadModule
in an included .conf file already; APXS does not have the ability to detect
that. Therefore, a "duplicate" LoadModule entry is added to httpd.conf by
APXS, and thus the clash occurs. This behavior has been reproduced
numerous times.
I think the RFC is pretty clear on how this works. Nobody else has
expressed confusion thus far. I could clarify further but I'm not sure
how; it's pretty straight-forward, really. I'm not sure what may have been
happening in your case or if perhaps you misunderstood what this RFC is
about. Either way, I would recommend you create a fresh Linux-based build
environment, build Apache 2.2 and PHP 5.3.10 yourself (i.e. stay away from
yum/apt-get), then attempt to generate an APXS-enabled Makefile using PHP's
configure script that does not activate APXS with the "-a" option. It
might also be a good idea for you to check-out the APXS documentation (I
included a link to it on the RFC).
Those steps should enable you to reproduce this. =)
--Kris
On Fri, Feb 24, 2012 at 4:02 PM, Christopher Jones <
christopher.jones@oracle.com> wrote:
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,It doesn't happen for me and I frequently build PHP 5.3, 5.4 and trunk
mods. The library name is the same for all branches. Are you sure
it's not a feature/bug of your APXS version? Anyway, the RFC needs
more investigative description, IMHO.Chirs
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
No, it happens and it's even clearly documented in APXS.
Basically, if you specify the "-a" option in APXS, it overwrites your
httpd.conf (or apache.conf or whatever it is on your system) and adds the
LoadModule line to it. In PHP's configure script, you'll notice that "-a"
is always specified; there's no option to use APXS without it. As a
result, "make install" will always overwrite your LoadModule entry in
httpd.conf if APXS is enabled. The problem occurs when you have LoadModule
in an included .conf file already; APXS does not have the ability to detect
that. Therefore, a "duplicate" LoadModule entry is added to httpd.conf by
APXS, and thus the clash occurs. This behavior has been reproduced
numerous times.
I can start with a LoadModule line, run the exact apxs command that
the PHP Makefile executes and I still have only one LoadModule in the
file. Note the time stamp of the file changes.
cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/httpd.conf
-rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:30 /home/cjones/apache22/conf/httpd.conf
cjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/httpd.conf
LoadModule php5_module modules/libphp5.so
cjones:~/phpbuild/php53 $ /home/cjones/apache22/bin/apxs -S LIBEXECDIR=/home/cjones/apache22/modules -S SYSCONFDIR=/home/cjones/apache22/conf -i -a -n php5 libphp5.la
/home/cjones/apache22/build/instdso.sh SH_LIBTOOL='/home/cjones/apache22/build/libtool' libphp5.la /home/cjones/apache22/modules
/home/cjones/apache22/build/libtool --mode=install cp libphp5.la /home/cjones/apache22/modules/
cp .libs/libphp5.so /home/cjones/apache22/modules/libphp5.so
cp .libs/libphp5.lai /home/cjones/apache22/modules/libphp5.la
libtool: install: warning: remember to run libtool --finish /home/cjones/phpbuild/php53 /libs' chmod 755 /home/cjones/apache22/modules/libphp5.so [activating modulephp5' in /home/cjones/apache22/conf/httpd.conf]
cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/httpd.conf
-rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:33 /home/cjones/apache22/conf/httpd.conf
cjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/httpd.conf
LoadModule php5_module modules/libphp5.so
I could interpolate the "apxs -a" documentation that says "or by
enabling it if it already exists" to support what I see.
Good luck with your RFC,
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Oh ok, I think I see where you're getting confused.
This problem occurs when your LoadModule statement is in a separate .conf
file; i.e. using the "Include" statement. APXS cannot detect this and just
sticks a LoadModule into the main .conf file. This is what causes the
duplication. It's a very common issue as many people (myself included)
prefer to keep their PHP configurations separate.
--Kris
On Fri, Feb 24, 2012 at 4:42 PM, Christopher Jones <
christopher.jones@oracle.com> wrote:
No, it happens and it's even clearly documented in APXS.
Basically, if you specify the "-a" option in APXS, it overwrites your
httpd.conf (or apache.conf or whatever it is on your system) and adds the
LoadModule line to it. In PHP's configure script, you'll notice that "-a"
is always specified; there's no option to use APXS without it. As a
result, "make install" will always overwrite your LoadModule entry in
httpd.conf if APXS is enabled. The problem occurs when you have
LoadModule
in an included .conf file already; APXS does not have the ability to
detect
that. Therefore, a "duplicate" LoadModule entry is added to httpd.conf by
APXS, and thus the clash occurs. This behavior has been reproduced
numerous times.I can start with a LoadModule line, run the exact apxs command that
the PHP Makefile executes and I still have only one LoadModule in the
file. Note the time stamp of the file changes.cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/**httpd.conf
-rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:30
/home/cjones/apache22/conf/**httpd.confcjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/**
httpd.conf
LoadModule php5_module modules/libphp5.socjones:~/phpbuild/php53 $ /home/cjones/apache22/bin/apxs -S
LIBEXECDIR=/home/cjones/**apache22/modules -S SYSCONFDIR=/home/cjones/**apache22/conf
-i -a -n php5 libphp5.la
/home/cjones/apache22/build/**instdso.sh SH_LIBTOOL='/home/cjones/**apache22/build/libtool'
libphp5.la /home/cjones/apache22/modules
/home/cjones/apache22/build/**libtool --mode=install cp libphp5.la/home/cjones/apache22/modules/
cp .libs/libphp5.so /home/cjones/apache22/modules/**libphp5.so
cp .libs/libphp5.lai /home/cjones/apache22/modules/**libphp5.lahttp://libphp5.la
libtool: install: warning: remember to runlibtool --finish /home/cjones/phpbuild/php53 /libs' chmod 755 /home/cjones/apache22/modules/**libphp5.so [activating modulephp5' in /home/cjones/apache22/conf/**httpd.conf]cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/**httpd.conf
-rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:33
/home/cjones/apache22/conf/**httpd.confcjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/**
httpd.conf
LoadModule php5_module modules/libphp5.soI could interpolate the "apxs -a" documentation that says "or by
enabling it if it already exists" to support what I see.Good luck with your RFC,
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Ok, I've updated the RFC based on input received here. I also made a
decision on the APXS vs. APXS2 question; please refer to the RFC for
details. If anybody has any objections to this decision, now would be the
time to say something!
I've targetted this for 5.4.1 so this won't have any bearing on the
upcoming 5.4.0 release. If I don't hear any new objections, I plan to
initiate the vote sometime early this week.
https://wiki.php.net/rfc/apxs-loadmodule
--Kris
Oh ok, I think I see where you're getting confused.
This problem occurs when your LoadModule statement is in a separate.conf file; i.e. using the "Include" statement. APXS cannot detect this
and just sticks a LoadModule into the main .conf file. This is what causes
the duplication. It's a very common issue as many people (myself included)
prefer to keep their PHP configurations separate.--Kris
On Fri, Feb 24, 2012 at 4:42 PM, Christopher Jones <
christopher.jones@oracle.com> wrote:No, it happens and it's even clearly documented in APXS.
Basically, if you specify the "-a" option in APXS, it overwrites your
httpd.conf (or apache.conf or whatever it is on your system) and adds the
LoadModule line to it. In PHP's configure script, you'll notice that
"-a"
is always specified; there's no option to use APXS without it. As a
result, "make install" will always overwrite your LoadModule entry in
httpd.conf if APXS is enabled. The problem occurs when you have
LoadModule
in an included .conf file already; APXS does not have the ability to
detect
that. Therefore, a "duplicate" LoadModule entry is added to httpd.conf
by
APXS, and thus the clash occurs. This behavior has been reproduced
numerous times.I can start with a LoadModule line, run the exact apxs command that
the PHP Makefile executes and I still have only one LoadModule in the
file. Note the time stamp of the file changes.cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/**httpd.conf
-rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:30
/home/cjones/apache22/conf/**httpd.confcjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/**
httpd.conf
LoadModule php5_module modules/libphp5.socjones:~/phpbuild/php53 $ /home/cjones/apache22/bin/apxs -S
LIBEXECDIR=/home/cjones/**apache22/modules -S SYSCONFDIR=/home/cjones/**apache22/conf
-i -a -n php5 libphp5.la
/home/cjones/apache22/build/**instdso.sh SH_LIBTOOL='/home/cjones/**apache22/build/libtool'
libphp5.la /home/cjones/apache22/modules
/home/cjones/apache22/build/**libtool --mode=install cp libphp5.la/home/cjones/apache22/modules/
cp .libs/libphp5.so /home/cjones/apache22/modules/**libphp5.so
cp .libs/libphp5.lai /home/cjones/apache22/modules/**libphp5.lahttp://libphp5.la
libtool: install: warning: remember to runlibtool --finish /home/cjones/phpbuild/php53 /libs' chmod 755 /home/cjones/apache22/modules/**libphp5.so [activating modulephp5' in /home/cjones/apache22/conf/**httpd.conf]cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/**httpd.conf
-rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:33
/home/cjones/apache22/conf/**httpd.confcjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/**
httpd.conf
LoadModule php5_module modules/libphp5.soI could interpolate the "apxs -a" documentation that says "or by
enabling it if it already exists" to support what I see.Good luck with your RFC,
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Kris Craig wrote:
Ok, I've updated the RFC based on input received here. I also made a
decision on the APXS vs. APXS2 question; please refer to the RFC for
details. If anybody has any objections to this decision, now would be the
time to say something!I've targetted this for 5.4.1 so this won't have any bearing on the
upcoming 5.4.0 release. If I don't hear any new objections, I plan to
initiate the vote sometime early this week.
Surely this is a purely distribution orientated problem? None of my linux
distributions have had this in httpd.conf for many years now. Just as extensions
within PHP are not managed from within php.ini
Surely the Ubuntu.package handler does the magic of updating the default
configuration to how THEY work ... most other distributions seen to follow their
own rules, and while it's taken me some time to appreciate, the SUSE structure
does work well ... for both apahce and PHP ... but I would not want to push that
as the right way either.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Ok, I've updated the RFC based on input received here. I also made a
decision on the APXS vs. APXS2 question; please refer to the RFC for
details. If anybody has any objections to this decision, now would be the
time to say something!I've targetted this for 5.4.1 so this won't have any bearing on the
upcoming 5.4.0 release. If I don't hear any new objections, I plan to
initiate the vote sometime early this week.https://wiki.php.net/rfc/apxs-loadmodule
--Kris
Heh, I like the idea the RFC is about.
Having one or several configuration files is just a matter of taste and
should be decided by distros package maintainers.
This RFC is about easing their lives, which is a good idea :)
I'm +1 for not supporting Apache1.x anymore, as it's been EOL'd anyway
(like th eRFC says).
Julien.P
Oh ok, I think I see where you're getting confused.
This problem occurs when your LoadModule statement is in a
separate.conf file; i.e. using the "Include" statement. APXS cannot
detect this
and just sticks a LoadModule into the main .conf file. This is what
causes
the duplication. It's a very common issue as many people (myself
included)
prefer to keep their PHP configurations separate.--Kris
On Fri, Feb 24, 2012 at 4:42 PM, Christopher Jones <
christopher.jones@oracle.com> wrote:No, it happens and it's even clearly documented in APXS.
Basically, if you specify the "-a" option in APXS, it overwrites your
httpd.conf (or apache.conf or whatever it is on your system) and adds
the
LoadModule line to it. In PHP's configure script, you'll notice that
"-a"
is always specified; there's no option to use APXS without it. As a
result, "make install" will always overwrite your LoadModule entry in
httpd.conf if APXS is enabled. The problem occurs when you have
LoadModule
in an included .conf file already; APXS does not have the ability to
detect
that. Therefore, a "duplicate" LoadModule entry is added to httpd.conf
by
APXS, and thus the clash occurs. This behavior has been reproduced
numerous times.I can start with a LoadModule line, run the exact apxs command that
the PHP Makefile executes and I still have only one LoadModule in the
file. Note the time stamp of the file changes.cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/**httpd.conf
-rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:30
/home/cjones/apache22/conf/**httpd.confcjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/**
httpd.conf
LoadModule php5_module modules/libphp5.socjones:~/phpbuild/php53 $ /home/cjones/apache22/bin/apxs -S
LIBEXECDIR=/home/cjones/**apache22/modules -S
SYSCONFDIR=/home/cjones/**apache22/conf
-i -a -n php5 libphp5.la
/home/cjones/apache22/build/**instdso.sh
SH_LIBTOOL='/home/cjones/**apache22/build/libtool'
libphp5.la /home/cjones/apache22/modules
/home/cjones/apache22/build/**libtool --mode=install cp
libphp5.la/home/cjones/apache22/modules/
cp .libs/libphp5.so /home/cjones/apache22/modules/**libphp5.so
cp .libs/libphp5.lai /home/cjones/apache22/modules/**libphp5.la<
http://libphp5.la>;
libtool: install: warning: remember to runlibtool --finish /home/cjones/phpbuild/php53 /libs' chmod 755 /home/cjones/apache22/modules/**libphp5.so [activating modulephp5' in /home/cjones/apache22/conf/**httpd.conf]cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/**httpd.conf
-rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:33
/home/cjones/apache22/conf/**httpd.confcjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/**
httpd.conf
LoadModule php5_module modules/libphp5.soI could interpolate the "apxs -a" documentation that says "or by
enabling it if it already exists" to support what I see.Good luck with your RFC,
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
No, it happens and it's even clearly documented in APXS.
Basically, if you specify the "-a" option in APXS, it overwrites your
httpd.conf (or apache.conf or whatever it is on your system) and adds
the
LoadModule line to it. In PHP's configure script, you'll notice that
"-a"
is always specified; there's no option to use APXS without it. As a
result, "make install" will always overwrite your LoadModule entry in
httpd.conf if APXS is enabled. The problem occurs when you have
LoadModule
in an included .conf file already; APXS does not have the ability to
detect
that. Therefore, a "duplicate" LoadModule entry is added to
httpd.conf by
APXS, and thus the clash occurs. This behavior has been reproduced
numerous times.I think the RFC is pretty clear on how this works. Nobody else has
expressed confusion thus far. I could clarify further but I'm not
sure
how; it's pretty straight-forward, really. I'm not sure what may have
been
happening in your case or if perhaps you misunderstood what this RFC
is
about. Either way, I would recommend you create a fresh Linux-based
build
environment, build Apache 2.2 and PHP 5.3.10 yourself (i.e. stay away
from
yum/apt-get), then attempt to generate an APXS-enabled Makefile using
PHP's
configure script that does not activate APXS with the "-a" option. It
might also be a good idea for you to check-out the APXS documentation
(I
included a link to it on the RFC).Those steps should enable you to reproduce this. =)
Once upon a time, a lonnnnnng time ago, I read through the configure /
make process, and I thought there was logic there to try to detect
if your httpd.conf diverged significantly from the default, and, if
so, it would choose NOT to add the LoadModule line, assuming you were
a power user who had it somewhere else...
I could be mis-remembering. This logic could have been removed. I
could be hallucinating. The logic I saw could have been doing
something entirely difference, as I have only a vague notion of how
configure/make works in the first place. It could have been some
other project.
Or this could account for your different experiences, based on whether
you "hacked" httpd.conf "enough" or started with a fresh out of the
box one and didn't touch it until after installing PHP.
ymmv
ianal
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
@Richard I think, briefly, something like that was implemented. However,
it was reverted soon after because it changed the default behavior of
configure. This was discovered to be a problem after people realized that,
if -a is not specified, APXS will not only skip writing the LoadModule
line, but for some inexplicable reason it will also strip the existing
LoadModule line if it's already there.
I'm guessing that's probably what you're remembering. This RFC differs in
that the default behavior of configure will remain unchanged.
@Lester Generally, this is a problem that surfaces in manual PHP builds.
You're correct in that the packaged repos tend to handle all that stuff for
you anyway. However, these repos are rarely updated (I think CentOS and
Ubuntu are both still stuck on 5.1), so it's often necessary to build PHP
manually if you want to take advantage of the latest features. In these
cases, being able to isolate the PHP configuration tends to make the most
sense, hence why this new option switch is necessary IMHO.
--Kris
No, it happens and it's even clearly documented in APXS.
Basically, if you specify the "-a" option in APXS, it overwrites your
httpd.conf (or apache.conf or whatever it is on your system) and adds
the
LoadModule line to it. In PHP's configure script, you'll notice that
"-a"
is always specified; there's no option to use APXS without it. As a
result, "make install" will always overwrite your LoadModule entry in
httpd.conf if APXS is enabled. The problem occurs when you have
LoadModule
in an included .conf file already; APXS does not have the ability to
detect
that. Therefore, a "duplicate" LoadModule entry is added to
httpd.conf by
APXS, and thus the clash occurs. This behavior has been reproduced
numerous times.I think the RFC is pretty clear on how this works. Nobody else has
expressed confusion thus far. I could clarify further but I'm not
sure
how; it's pretty straight-forward, really. I'm not sure what may have
been
happening in your case or if perhaps you misunderstood what this RFC
is
about. Either way, I would recommend you create a fresh Linux-based
build
environment, build Apache 2.2 and PHP 5.3.10 yourself (i.e. stay away
from
yum/apt-get), then attempt to generate an APXS-enabled Makefile using
PHP's
configure script that does not activate APXS with the "-a" option. It
might also be a good idea for you to check-out the APXS documentation
(I
included a link to it on the RFC).Those steps should enable you to reproduce this. =)
Once upon a time, a lonnnnnng time ago, I read through the configure /
make process, and I thought there was logic there to try to detect
if your httpd.conf diverged significantly from the default, and, if
so, it would choose NOT to add the LoadModule line, assuming you were
a power user who had it somewhere else...I could be mis-remembering. This logic could have been removed. I
could be hallucinating. The logic I saw could have been doing
something entirely difference, as I have only a vague notion of how
configure/make works in the first place. It could have been some
other project.Or this could account for your different experiences, based on whether
you "hacked" httpd.conf "enough" or started with a fresh out of the
box one and didn't touch it until after installing PHP.ymmv
ianal--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Kris Craig wrote:
@Lester Generally, this is a problem that surfaces in manual PHP builds.
You're correct in that the packaged repos tend to handle all that stuff for
you anyway. However, these repos are rarely updated (I think CentOS and
Ubuntu are both still stuck on 5.1), so it's often necessary to build PHP
manually if you want to take advantage of the latest features. In these
cases, being able to isolate the PHP configuration tends to make the most
sense, hence why this new option switch is necessary IMHO.
I've obviously been doing something wrong then :)
SUSE has been keeping my versions up to date quite happily even to the extent
that I now have to make sure I DON'T get an update applied until I've had a
chance to check the live sites!
But I still have to manually build the more useful extensions that are not
included, and it's at this time that the build 'defaults' tends to screw with
the SUSE configuration :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
@Lester Generally, this is a problem that surfaces in manual PHP builds.
You're correct in that the packaged repos tend to handle all that stuff for
you anyway. However, these repos are rarely updated (I think CentOS and
Ubuntu are both still stuck on 5.1), so it's often necessary to build PHP
manually if you want to take advantage of the latest features. In these
cases, being able to isolate the PHP configuration tends to make the most
sense, hence why this new option switch is necessary IMHO.
AFAIR centos 5.7 provides php 5.2.1
(centos 4 has only Maintenance updates, for 2 more days)
the oldest ubuntu (8,04 lts) also have 5.2.4
so I think that the only distro with support that ships >=5.2 is rhel 4
with the Extended life cycle.
but usually there are semi-official/community repos providing more
up-to-date versions for each distribution.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I've got a CentOS 5.7 VM running at work and the PHP package returned by
yum is 5.1.6. Don't have my Ubuntu box with me at the moment but I'm
pretty sure it's 5.1.x as well.
You probably have rpmforge or CentALT enabled and that's where it's pulling
the newer build. But even then, the latest one you'll get is 5.2.17. I'm
not aware of any widely available repos that have 5.3.x.
--Kris
@Lester Generally, this is a problem that surfaces in manual PHP builds.
You're correct in that the packaged repos tend to handle all that stuff
for
you anyway. However, these repos are rarely updated (I think CentOS and
Ubuntu are both still stuck on 5.1), so it's often necessary to build PHP
manually if you want to take advantage of the latest features. In these
cases, being able to isolate the PHP configuration tends to make the most
sense, hence why this new option switch is necessary IMHO.AFAIR centos 5.7 provides php 5.2.1
(centos 4 has only Maintenance updates, for 2 more days)
the oldest ubuntu (8,04 lts) also have 5.2.4
so I think that the only distro with support that ships >=5.2 is rhel 4
with the Extended life cycle.
but usually there are semi-official/community repos providing more
up-to-date versions for each distribution.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I've got a CentOS 5.7 VM running at work and the PHP package returned by
yum is 5.1.6. Don't have my Ubuntu box with me at the moment but I'm
pretty sure it's 5.1.x as well.You probably have rpmforge or CentALT enabled and that's where it's
pulling the newer build. But even then, the latest one you'll get is
5.2.17. I'm not aware of any widely available repos that have 5.3.x.--Kris
just checked, centos 5 provides php53 packages, see
http://mirror.centos.org/centos/5/os/i386/CentOS/ .
and here is the semi-official centos repo that I mentioned:
http://dev.centos.org/centos/5/testing/i386/RPMS/
oldest ubuntu (hardy) provides 5.2.4: http://packages.ubuntu.com/hardy/php5
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Yes but you have to download those RPM's manually. If you just use the
default repo (i.e. "yum install php") as most sysadmins do, you're gonna
get something MUCH older than that. Plus there are still occasions where a
manual build is preferable to using an RPM.
--Kris
I've got a CentOS 5.7 VM running at work and the PHP package returned by
yum is 5.1.6. Don't have my Ubuntu box with me at the moment but I'm
pretty sure it's 5.1.x as well.You probably have rpmforge or CentALT enabled and that's where it's
pulling the newer build. But even then, the latest one you'll get is
5.2.17. I'm not aware of any widely available repos that have 5.3.x.--Kris
just checked, centos 5 provides php53 packages, see
http://mirror.centos.org/centos/5/os/i386/CentOS/ .
and here is the semi-official centos repo that I mentioned:
http://dev.centos.org/centos/5/testing/i386/RPMS/
oldest ubuntu (hardy) provides 5.2.4:
http://packages.ubuntu.com/hardy/php5--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
No, you don't. Since CentOS 5.6, PHP 5.3 is part of the base
repository. You are right, "yum install php" installs 5.1, but you
don't have to download anything to install 5.3, just type "yum install
php53".
Gergo Erdosi
Yes but you have to download those RPM's manually. If you just use the
default repo (i.e. "yum install php") as most sysadmins do, you're gonna
get something MUCH older than that. Plus there are still occasions where a
manual build is preferable to using an RPM.--Kris
Hmm didn't know that. I stand corrected!
That being said, unless we're talking about dropping the configure script
altogether in favor of reliance on RPM's and repos, this RFC is still a
no-brainer. =)
--Kris
No, you don't. Since CentOS 5.6, PHP 5.3 is part of the base
repository. You are right, "yum install php" installs 5.1, but you
don't have to download anything to install 5.3, just type "yum install
php53".Gergo Erdosi
Yes but you have to download those RPM's manually. If you just use the
default repo (i.e. "yum install php") as most sysadmins do, you're gonna
get something MUCH older than that. Plus there are still occasions
where a
manual build is preferable to using an RPM.--Kris
Are there any final thoughts, objections, last-minute change requests,
etc? Looks like we're all pretty much in agreement so I'll initiate the
vote if I don't hear anything.
--Kris
Hmm didn't know that. I stand corrected!
That being said, unless we're talking about dropping the configure script
altogether in favor of reliance on RPM's and repos, this RFC is still a
no-brainer. =)--Kris
On Mon, Feb 27, 2012 at 3:56 PM, Gergo Erdosi gergo@gergoerdosi.comwrote:
No, you don't. Since CentOS 5.6, PHP 5.3 is part of the base
repository. You are right, "yum install php" installs 5.1, but you
don't have to download anything to install 5.3, just type "yum install
php53".Gergo Erdosi
On Tue, Feb 28, 2012 at 12:06 AM, Kris Craig kris.craig@gmail.com
wrote:Yes but you have to download those RPM's manually. If you just use the
default repo (i.e. "yum install php") as most sysadmins do, you're gonna
get something MUCH older than that. Plus there are still occasions
where a
manual build is preferable to using an RPM.--Kris