enabling postgresql by default View as Markdown

Since there's been a lot of talk about disabling mysql by
default (and
having another option available), the PostgreSQL people are
pretty excited
about this and are keen to see what can be done about getting
postgres
enabled by default instead.

I certainly don't speak for all. But I would like to throw my hat in on
this -- why not stop enabling stuff by default ... We really don't need
to. Many developers complain that our users are stupid, or whatever
other discrediting statement that seems to be in fashion. By educating
them (ie, helping them along a little, requiring that they get to know
./configure options) the chances are that they will not appear to be
quite so stupid anymore.

Ok. Getting to a point: bundling things is PHP telling users what tools
they should use. Yes, there is --without-<foo> but it doesn't help a
newer user, and it certainly doesn't show that we are adhering to some
sort of standard about enabling by default, and bundling comes into it
too.

Therefore, I propose that we:

-- limit bundled code to only code that is either hard to find and
install or we have chosen to fork (eg, gd), or is core code which we can
not live without. (i.e. the build fails -- eg, pcre).

-- limit enabled-by-default extensions to only those which have a
significant reasoning behind it (ie, like pcre, which is core code and
would cause breakages without it), AND comes along with 10 positive
votes for enabling.

I admit that perhaps these guidelines are not encompassing, and I can
already see loopholes. I encourage other members of this list to propose
changes and enhancements, but one thing we must prevent is this notion
of bundling/enabling code based on the whim and fancy of one or a few
developers. PHP doesn't need to become known as PHP with CPANesque bloat
attached on.

I look forward to the day where we can distribute a version of php with
just the engine, the build system, main/ and ext/standard - the real
core of PHP.

Since there's been a lot of talk about disabling mysql by default (and
having another option available), the PostgreSQL people are pretty excited
about this and are keen to see what can be done about getting postgres
enabled by default instead.

What do people think about this?

We're not bundling the library with PHP, so we can not enable it by
default.

Derick

--
"Interpreting what the GPL actually means is a job best left to those
that read the future by examining animal entrails."

Derick Rethans http://derickrethans.nl/
International PHP Magazine http://php-mag.net/

I suggest we don't open this discussion again. The archives are full of
past discussions. We'll continue with the status-quo barring major, tiring
discussions to change it.

Zeev

At 09:50 24/06/2003, James Cox wrote:

Since there's been a lot of talk about disabling mysql by
default (and
having another option available), the PostgreSQL people are
pretty excited
about this and are keen to see what can be done about getting
postgres
enabled by default instead.

I certainly don't speak for all. But I would like to throw my hat in on
this -- why not stop enabling stuff by default ... We really don't need
to. Many developers complain that our users are stupid, or whatever
other discrediting statement that seems to be in fashion. By educating
them (ie, helping them along a little, requiring that they get to know
./configure options) the chances are that they will not appear to be
quite so stupid anymore.

Ok. Getting to a point: bundling things is PHP telling users what tools
they should use. Yes, there is --without-<foo> but it doesn't help a
newer user, and it certainly doesn't show that we are adhering to some
sort of standard about enabling by default, and bundling comes into it
too.

Therefore, I propose that we:

-- limit bundled code to only code that is either hard to find and
install or we have chosen to fork (eg, gd), or is core code which we can
not live without. (i.e. the build fails -- eg, pcre).

-- limit enabled-by-default extensions to only those which have a
significant reasoning behind it (ie, like pcre, which is core code and
would cause breakages without it), AND comes along with 10 positive
votes for enabling.

I admit that perhaps these guidelines are not encompassing, and I can
already see loopholes. I encourage other members of this list to propose
changes and enhancements, but one thing we must prevent is this notion
of bundling/enabling code based on the whim and fancy of one or a few
developers. PHP doesn't need to become known as PHP with CPANesque bloat
attached on.

I look forward to the day where we can distribute a version of php with
just the engine, the build system, main/ and ext/standard - the real
core of PHP.