I notice that there are a number of places in HEAD where php 5 is still
mentioned - some build targets, file names, etc. Is there any reason for
it or it's just an omission and eventually only php 6 should be ever
mentioned in this branch?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
The whole idea of having that number there is pretty stupid..why not just remove
them altogether..?
--Jani
Stanislav Malyshev kirjoitti:
I notice that there are a number of places in HEAD where php 5 is still
mentioned - some build targets, file names, etc. Is there any reason for
it or it's just an omission and eventually only php 6 should be ever
mentioned in this branch?
The whole idea of having that number there is pretty stupid..why not
just remove them altogether..?
Could work too :)
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
The whole idea of having that number there is pretty stupid..why not just remove
them altogether..?
Well, in some places it's just not possible, like libphp6.so etc.
Other places should be fixed, of course.
Actually I have a patch for some SAPIs, just didn't have time to test and commit it.
Stanislav Malyshev kirjoitti:
I notice that there are a number of places in HEAD where php 5 is still
mentioned - some build targets, file names, etc. Is there any reason for
it or it's just an omission and eventually only php 6 should be ever
mentioned in this branch?
--
Wbr,
Antony Dovgal
Antony Dovgal kirjoitti:
The whole idea of having that number there is pretty stupid..why not
just remove them altogether..?Well, in some places it's just not possible, like libphp6.so etc.
You chose just the right example! Now, can you tell why it is necessary?
And remember, everything is possible..there is no impossible here, we're
having a totally new major version and everything.
--Jani
Antony Dovgal kirjoitti:
The whole idea of having that number there is pretty stupid..why not
just remove them altogether..?Well, in some places it's just not possible, like libphp6.so etc.
You chose just the right example! Now, can you tell why it is necessary?
And remember, everything is possible..there is no impossible here, we're
having a totally new major version and everything.
Well, you might want to have both libphp5.so and libphp6.so installed, but only one of them enabled.
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
Antony Dovgal kirjoitti:
The whole idea of having that number there is pretty stupid..why not
just remove them altogether..?Well, in some places it's just not possible, like libphp6.so etc.
You chose just the right example! Now, can you tell why it is necessary?
And remember, everything is possible..there is no impossible here, we're
having a totally new major version and everything.Well, you might want to have both libphp5.so and libphp6.so installed,
but only one of them enabled.
Why should you be able to do this for two different major versions, but
not for arbitrary minor versions or even configurations?
regards,
Lukas
Antony Dovgal wrote:
Antony Dovgal kirjoitti:
The whole idea of having that number there is pretty stupid..why not
just remove them altogether..?Well, in some places it's just not possible, like libphp6.so etc.
You chose just the right example! Now, can you tell why it is necessary?
And remember, everything is possible..there is no impossible here, we're
having a totally new major version and everything.Well, you might want to have both libphp5.so and libphp6.so installed,
but only one of them enabled.Why should you be able to do this for two different major versions, but
not for arbitrary minor versions or even configurations?
Because this is how it works for years?
I do agree that having version number in file names is bad idea, but we need to think
it over very good, since I don't like changing a behaviour which existed for ages,
even if it looks stupid.
--
Wbr,
Antony Dovgal
"worked for years" is just why I said "having a totally new major
version"..meaning this is the time to fix the bad practises.
For filenames this is no problem at all, you can always rename files
yourself if you really need to have different files around.
And if you think that this breaks something..well, it doesn't.
The old libphp4.so, and libphp5.so aren't changing with this, are they? :D
--Jani
Antony Dovgal kirjoitti:
Antony Dovgal wrote:
Antony Dovgal kirjoitti:
The whole idea of having that number there is pretty stupid..why
not just remove them altogether..?Well, in some places it's just not possible, like libphp6.so etc.
You chose just the right example! Now, can you tell why it is
necessary?
And remember, everything is possible..there is no impossible here,
we're
having a totally new major version and everything.Well, you might want to have both libphp5.so and libphp6.so
installed, but only one of them enabled.Why should you be able to do this for two different major versions,
but not for arbitrary minor versions or even configurations?Because this is how it works for years?
I do agree that having version number in file names is bad idea, but we
need to think it over very good, since I don't like changing a behaviour
which existed for ages, even if it looks stupid.
"worked for years" is just why I said "having a totally new major
version"..meaning this is the time to fix the bad practises.
For filenames this is no problem at all, you can always rename files
yourself if you really need to have different files around.And if you think that this breaks something..well, it doesn't.
The old libphp4.so, and libphp5.so aren't changing with this, are they? :D
Right, but the World Order [tm] does =)
--
Wbr,
Antony Dovgal
And if you think that this breaks something..well, it doesn't.
The old libphp4.so, and libphp5.so aren't changing with this, are
they? :DRight, but the World Order [tm] does =)
Looking at how Unix shared libs are named customary, there's a
considerable part of those bearing major versions in their names
(libc6.so, libxml2.so, etc.). So for .so it's probably OK to stay with
version. However, that doesn't mean, for example, project files should
stay with version - i.e. that there should be files in the repository
named php5.* or libphp5.*. Unless of course there's some limitation from
the autolools/libtool side. I think windows doesn't have any problem
with that anyway, so we could weed out all those php5.dsp etc.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
If, for exemple, you want to run PHP4 and PHP5 on two different instances of
Apache using the same Apache binary (but two different httpd.conf), it's
useful to have them named libphp4.so and libphp5.so because `make install'
automatically throws the library where apxs tells it to.
If the major version number is dropped, not only will it be inconsistent
with the previous names, it will also mix things up.
My 2 cents.
"worked for years" is just why I said "having a totally new major
version"..meaning this is the time to fix the bad practises.
For filenames this is no problem at all, you can always rename files
yourself if you really need to have different files around.And if you think that this breaks something..well, it doesn't.
The old libphp4.so, and libphp5.so aren't changing with this, are they? :D--Jani
Antony Dovgal kirjoitti:
Antony Dovgal wrote:
Antony Dovgal kirjoitti:
The whole idea of having that number there is pretty stupid..why
not just remove them altogether..?Well, in some places it's just not possible, like libphp6.so etc.
You chose just the right example! Now, can you tell why it is
necessary?
And remember, everything is possible..there is no impossible here,
we're
having a totally new major version and everything.Well, you might want to have both libphp5.so and libphp6.so
installed, but only one of them enabled.Why should you be able to do this for two different major versions,
but not for arbitrary minor versions or even configurations?Because this is how it works for years?
I do agree that having version number in file names is bad idea, but we
need to think it over very good, since I don't like changing a behaviour
which existed for ages, even if it looks stupid.--
--
Nicolas Bérard-Nault (nicobn@gmail.com)
Étudiant D.E.C. Sciences, Lettres & Arts
Cégep de Sherbrooke
Page personnelle: http://nicobn.googlepages.com
Correct me if I'm wrong, but for those "just not possible" cases, a
single version-constant in the source would suffice, right? So it's at
least not inconsistent...
Regards,
Stefan
This is when I use concept called "rename" when I copy these babies around.. :D
And as you knew, it's not possible (anymore) to have both enabled in same apache
instance anyway.
--Jani
Antony Dovgal kirjoitti:
Antony Dovgal kirjoitti:
The whole idea of having that number there is pretty stupid..why not
just remove them altogether..?Well, in some places it's just not possible, like libphp6.so etc.
You chose just the right example! Now, can you tell why it is necessary?
And remember, everything is possible..there is no impossible here, we're
having a totally new major version and everything.Well, you might want to have both libphp5.so and libphp6.so installed,
but only one of them enabled.
Antony Dovgal kirjoitti:
The whole idea of having that number there is pretty stupid..why
not
just remove them altogether..?Well, in some places it's just not possible, like libphp6.so etc.
You chose just the right example! Now, can you tell why it is
necessary?
And remember, everything is possible..there is no impossible here,
we're
having a totally new major version and everything.
I'd rather not have my old libphp#.so file over-written when I install
a new version, in case things go horribly wrong and I want to just
roll-back...
But maybe that's just me...
There was a time where one could have 2 php mod versions running at
once, as I recall, and having different filenames was kinda important,
eh?
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
I'd rather not have my old libphp#.so file over-written when I install
a new version, in case things go horribly wrong and I want to just
roll-back...
Then you have the same reason to worry right now - every php5 install
from 5.0.0 to 5.2.3 overwrites libphp5.so.
There was a time where one could have 2 php mod versions running at
once, as I recall, and having different filenames was kinda important,
eh?
Well, there was a setting that kinda allowed that, but I'm not sure it
ever worked correctly - there are all sorts of symbol clashes, etc.
On the other hand, you can happily run two (or a dozen :) PHP versions
right now - just install any FastCGI implementation, compile two
cgi-fcgi PHPs and install. Only thing you would need to care about is to
give them separate php.ini's and/or separate extension directories.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Hi,
Why isn't the Apache module appended with the same suffix as the other
binaries (configuration option --program-suffix). It seems like the
logical solution here. That way you can have any different versions if
you want, but the default is just the overwrite.
Best regards,
Arnold
Stanislav Malyshev wrote:
I'd rather not have my old libphp#.so file over-written when I install
a new version, in case things go horribly wrong and I want to just
roll-back...Then you have the same reason to worry right now - every php5 install
from 5.0.0 to 5.2.3 overwrites libphp5.so.There was a time where one could have 2 php mod versions running at
once, as I recall, and having different filenames was kinda important,
eh?Well, there was a setting that kinda allowed that, but I'm not sure it
ever worked correctly - there are all sorts of symbol clashes, etc.On the other hand, you can happily run two (or a dozen :) PHP versions
right now - just install any FastCGI implementation, compile two
cgi-fcgi PHPs and install. Only thing you would need to care about is
to give them separate php.ini's and/or separate extension directories.
Because it's --program-suffix and not --library-suffix.
--Jani
Hi,
Why isn't the Apache module appended with the same suffix as the other
binaries (configuration option --program-suffix). It seems like the
logical solution here. That way you can have any different versions if
you want, but the default is just the overwrite.Best regards,
ArnoldStanislav Malyshev wrote:
I'd rather not have my old libphp#.so file over-written when I install
a new version, in case things go horribly wrong and I want to just
roll-back...Then you have the same reason to worry right now - every php5 install
from 5.0.0 to 5.2.3 overwrites libphp5.so.There was a time where one could have 2 php mod versions running at
once, as I recall, and having different filenames was kinda important,
eh?Well, there was a setting that kinda allowed that, but I'm not sure it
ever worked correctly - there are all sorts of symbol clashes, etc.On the other hand, you can happily run two (or a dozen :) PHP versions
right now - just install any FastCGI implementation, compile two
cgi-fcgi PHPs and install. Only thing you would need to care about is
to give them separate php.ini's and/or separate extension directories.
When you build the Apache2 SAPI the only binary build is the module, so
'--program-suffix' is unused. Anyway it doesn't have to be the same
configuration option per say (though I don't see why not), but the
method of specifying the suffix with configure is much handier than
having it hard-coded in source. I've stated the reasons in the previous
e-mail.
Best regards,
Arnold
Jani Taskinen wrote:
Because it's --program-suffix and not --library-suffix.
--Jani
Hi,
Why isn't the Apache module appended with the same suffix as the other
binaries (configuration option --program-suffix). It seems like the
logical solution here. That way you can have any different versions if
you want, but the default is just the overwrite.Best regards,
ArnoldStanislav Malyshev wrote:
I'd rather not have my old libphp#.so file over-written when I install
a new version, in case things go horribly wrong and I want to just
roll-back...Then you have the same reason to worry right now - every php5 install
from 5.0.0 to 5.2.3 overwrites libphp5.so.There was a time where one could have 2 php mod versions running at
once, as I recall, and having different filenames was kinda important,
eh?Well, there was a setting that kinda allowed that, but I'm not sure it
ever worked correctly - there are all sorts of symbol clashes, etc.On the other hand, you can happily run two (or a dozen :) PHP versions
right now - just install any FastCGI implementation, compile two
cgi-fcgi PHPs and install. Only thing you would need to care about is
to give them separate php.ini's and/or separate extension directories.
It's actually not the only binary/script that is build.
--program-suffix|prefix affect also phpize, etc. scripts names.
And AFAIK, CLI binary is always build unless of course you disable it. :)
Patches are welcome.
--Jani
Arnold Daniels kirjoitti:
When you build the Apache2 SAPI the only binary build is the module, so
'--program-suffix' is unused. Anyway it doesn't have to be the same
configuration option per say (though I don't see why not), but the
method of specifying the suffix with configure is much handier than
having it hard-coded in source. I've stated the reasons in the previous
e-mail.Best regards,
ArnoldJani Taskinen wrote:
Because it's --program-suffix and not --library-suffix.
--Jani
Hi,
Why isn't the Apache module appended with the same suffix as the other
binaries (configuration option --program-suffix). It seems like the
logical solution here. That way you can have any different versions if
you want, but the default is just the overwrite.Best regards,
ArnoldStanislav Malyshev wrote:
I'd rather not have my old libphp#.so file over-written when I install
a new version, in case things go horribly wrong and I want to just
roll-back...Then you have the same reason to worry right now - every php5 install
from 5.0.0 to 5.2.3 overwrites libphp5.so.There was a time where one could have 2 php mod versions running at
once, as I recall, and having different filenames was kinda important,
eh?Well, there was a setting that kinda allowed that, but I'm not sure it
ever worked correctly - there are all sorts of symbol clashes, etc.On the other hand, you can happily run two (or a dozen :) PHP versions
right now - just install any FastCGI implementation, compile two
cgi-fcgi PHPs and install. Only thing you would need to care about is
to give them separate php.ini's and/or separate extension directories.
Sure you're right. I always build the SAPI alone, which is the debian
style. So in my mind this was always the case, but in fact it is not.
Anyway I think a '--libary-suffix' would do the trick nicely.
Best regards,
Arnold
Jani Taskinen wrote:
It's actually not the only binary/script that is build.
--program-suffix|prefix affect also phpize, etc. scripts names.
And AFAIK, CLI binary is always build unless of course you disable it. :)Patches are welcome.
--Jani
Arnold Daniels kirjoitti:
When you build the Apache2 SAPI the only binary build is the module,
so '--program-suffix' is unused. Anyway it doesn't have to be the
same configuration option per say (though I don't see why not), but
the method of specifying the suffix with configure is much handier
than having it hard-coded in source. I've stated the reasons in the
previous e-mail.Best regards,
ArnoldJani Taskinen wrote:
Because it's --program-suffix and not --library-suffix.
--Jani
Hi,
Why isn't the Apache module appended with the same suffix as the
other binaries (configuration option --program-suffix). It seems
like the logical solution here. That way you can have any different
versions if you want, but the default is just the overwrite.Best regards,
ArnoldStanislav Malyshev wrote:
I'd rather not have my old libphp#.so file over-written when I
install
a new version, in case things go horribly wrong and I want to just
roll-back...Then you have the same reason to worry right now - every php5
install from 5.0.0 to 5.2.3 overwrites libphp5.so.There was a time where one could have 2 php mod versions running at
once, as I recall, and having different filenames was kinda
important,
eh?Well, there was a setting that kinda allowed that, but I'm not
sure it ever worked correctly - there are all sorts of symbol
clashes, etc.On the other hand, you can happily run two (or a dozen :) PHP
versions right now - just install any FastCGI implementation,
compile two cgi-fcgi PHPs and install. Only thing you would need
to care about is to give them separate php.ini's and/or separate
extension directories.