Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[Boian Bonev]

> > i'd also preffer to have both versions - on all of my production servers
i
> > do install both apache module and cgi version. the latter i use for cron
> > jobs, background processing and whatsoever tasks that need to do
something
> > outside the web. so in my opinion both sapi module and cgi will be a
fine
> > default. one more 'little' binary in /usr/local/bin would harm noone.
also
> > some isp configurations with several sapi setups on the same machine
would
> > benefit easier maintenance with this option. of course a way to disable
it
> > is ok but since PEAR needs the cgi ver to be able to fetch modules and
etc
> > the default should be 'enabled'.
> Also it make sense to separate all but SAPI modules into shared library
> to which SAPI module is linked dynamically. Then SAPI module binaries will
> all share one code.

indeed this is only one more step in the build process - make the core php
lib then link to all the sapi modules on the configure command line and
install them one by one. you did not mean dll/so right? because the base
library must be a static one and then the sapi modules themselves may be
either dynamic or static...

b.


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[Alexander Bokovoy]

On Wed, Apr 11, 2001 at 01:06:56PM +0300, Boian Bonev wrote:
> > > > Perhaps optionally disabled.. --without-cgi?
> > > I would go for optionally on, I really dont want to build both the
> apache
> > > module (p.e.) AND the CGi at the same time. For QA testing this is fine,
> > > but not for production servers.
> >
> > If you want to use the PEAR tools, you need the CGI version.  These
> > are definitely intended for production servers.
> >
> 
> i'd also preffer to have both versions - on all of my production servers i
> do install both apache module and cgi version. the latter i use for cron
> jobs, background processing and whatsoever tasks that need to do something
> outside the web. so in my opinion both sapi module and cgi will be a fine
> default. one more 'little' binary in /usr/local/bin would harm noone. also
> some isp configurations with several sapi setups on the same machine would
> benefit easier maintenance with this option. of course a way to disable it
> is ok but since PEAR needs the cgi ver to be able to fetch modules and etc
> the default should be 'enabled'.
Also it make sense to separate all but SAPI modules into shared library
to which SAPI module is linked dynamically. Then SAPI module binaries will
all share one code.
-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[Boian Bonev]

> > > Perhaps optionally disabled.. --without-cgi?
> > I would go for optionally on, I really dont want to build both the
apache
> > module (p.e.) AND the CGi at the same time. For QA testing this is fine,
> > but not for production servers.
>
> If you want to use the PEAR tools, you need the CGI version.  These
> are definitely intended for production servers.
>

i'd also preffer to have both versions - on all of my production servers i
do install both apache module and cgi version. the latter i use for cron
jobs, background processing and whatsoever tasks that need to do something
outside the web. so in my opinion both sapi module and cgi will be a fine
default. one more 'little' binary in /usr/local/bin would harm noone. also
some isp configurations with several sapi setups on the same machine would
benefit easier maintenance with this option. of course a way to disable it
is ok but since PEAR needs the cgi ver to be able to fetch modules and etc
the default should be 'enabled'.

b.




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[Stig Sæther Bakken]

[Derick Rethans <[EMAIL PROTECTED]>]
> On Mon, 9 Apr 2001, James Moore wrote:
> 
> >
> > > > 4. The CGI version of PHP is always built and installed.
> > >
> > > I think this should be optional.
> >
> > Perhaps optionally disabled.. --without-cgi?
> 
> I would go for optionally on, I really dont want to build both the apache
> module (p.e.) AND the CGi at the same time. For QA testing this is fine,
> but not for production servers.

If you want to use the PEAR tools, you need the CGI version.  These
are definitely intended for production servers.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[Stig Sæther Bakken]

[Jon Parise <[EMAIL PROTECTED]>]
> On Sun, Apr 08, 2001 at 06:21:50PM -0400, Stig Sther Bakken wrote:
> 
> > 1. Using --datadir to determine where PEAR PHP files go.  With
> >--datadir=/usr/share or --datadir=/usr/share/php, PHP architecture
> >independent files go to /usr/share/php, and PEAR's PHP files go to
> >/usr/share/php/pear.
> > 
> >I've added your --with-pear option to override this.
> > 
> > 2. Using --libdir to determine where extensions go.  With
> >--libdir=/usr/lib or --libdir=/usr/lib/php, extensions are
> >installed in /usr/lib/php/.  I've also shortened the
> > part so "no-debug" and "non-zts" are skipped.  The 
> >alternatives are now "20001222", "20001222-zts", "20001222-debug"
> >and "20001222-zts-debug".
> 
> Both of these sounds good to me.
>  
> > 3. Using --sysconfdir to determine php.ini path.  The default is now
> >$prefix/etc.
> 
> Would this be a replacement for --with-config-file-path?

It sets a default, and you can make do with only --sysconfdir, but
right now --with-config-file-path overrides it.

> > 4. The CGI version of PHP is always built and installed.
> 
> I assume that would --bindir, right?

Yup.

> > Let me know if you have any problems with these changes.  They should
> > make it a lot easier for distributions to build PHP, because we
> > conform more to de-facto build conventions (at least on Linux).  Also
> > you won't have to re-run configure and make to build the CGI in order
> > to run tests, the PEAR installer etc.
> 
> I think you're proposed changes cover a lot more (useful) ground than
> my simple patch.  Go for it! =)

I'm going, I'm going. :-)

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[Anil Madhavapeddy]

Sascha Schumann wrote:
>
> No.  The alternative is to pass --enable-cgi on the command-line.

?

This doesn't work (nor is it listed in the --help options to configure)
I mean to compile a CGI and APXS DSO in a single compile, not two.  My
understanding is that only one SAPI module can be selected at a time
right now.  I would love to stand corrected; it's one of my prime
problems with the OpenBSD port right now.

> If the administrator installs it unknowingly, the CGI might
> get installed with inproper permissions which lead to
> potential security problems.

It's not SUID, so what's the problem?  A clear note in the NEWS file
that this behaviour has changed should be enough for administrators of
chrooted or otherwise secured systems (if they blindly update without
examining changes, then they aren't running a very tight ship anyway).

> I respect the wishes of the QA
> team, but please don't force your will upon all PHP users in
> exchange for a bit of convenience.

If PHP doesn't start installing a CGI by default, then PEAR is going to
have a few problems - its installer depends on that CGI.  And how many
end users actually run regression tests right now?  If the CGI is there
in /usr/local/bin, then a lot more users can do this, instead of just
the small QA team.  CPAN feedback from 'make test' must be quite useful
to them ...

Anil


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PEAR-DEV] Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[Chuck Hagenbuch]

Quoting Derick Rethans <[EMAIL PROTECTED]>:

> I would go for optionally on, I really dont want to build both the apache
> module (p.e.) AND the CGi at the same time. For QA testing this is fine,
> but not for production servers.

But if the PEAR installer is going to depend on the cgi version of php, we're
going to need it installed on machines by default. Making people build php twice
in order to use PEAR is going to kill user acceptance.

-chuck

--
Charles Hagenbuch, <[EMAIL PROTECTED]>
Number of U.S. nuclear bombs lost in accidents and never recovered: 11

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV]--with-pear[=DIR] patch

[Sascha Schumann]

On Mon, 9 Apr 2001, Anil Madhavapeddy wrote:

> Derick Rethans wrote:
> >
> > I would go for optionally on, I really dont want to build both
> > the apache module (p.e.) AND the CGi at the same time.
> > For QA testing this is fine, but not for production servers.
>
> Well, it really beats the alternative, which is to compile everything
> twice

No.  The alternative is to pass --enable-cgi on the command-line.

> ... what's wrong with having a PHP cgi sitting around on a
> production server by the way?  It's very handy when trying to debug
> stuff, and doesn't intrude on any normal processes either.

If the administrator installs it unknowingly, the CGI might
get installed with inproper permissions which lead to
potential security problems.  I respect the wishes of the QA
team, but please don't force your will upon all PHP users in
exchange for a bit of convenience.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[Anil Madhavapeddy]

Derick Rethans wrote:
>
> I would go for optionally on, I really dont want to build both
> the apache module (p.e.) AND the CGi at the same time.
> For QA testing this is fine, but not for production servers.

Well, it really beats the alternative, which is to compile everything
twice ... what's wrong with having a PHP cgi sitting around on a
production server by the way?  It's very handy when trying to debug
stuff, and doesn't intrude on any normal processes either.

Anil


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV]--with-pear[=DIR] patch

[Sascha Schumann]

On Mon, 9 Apr 2001, James Moore wrote:

>
> > > 4. The CGI version of PHP is always built and installed.
> >
> > I think this should be optional.
>
> Perhaps optionally disabled.. --without-cgi?

First, it is a boolean feature, hence enable/disable would be
correct.  Second, defaulting to the behaviour of prior
releases is IMHO the best option for minor releases.  If we
decide that it is indeed a useful feature, we can enable it
by default in 4.1.x (or whatever comes next).

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV]--with-pear[=DIR] patch

[Derick Rethans]

On Mon, 9 Apr 2001, James Moore wrote:

>
> > > 4. The CGI version of PHP is always built and installed.
> >
> > I think this should be optional.
>
> Perhaps optionally disabled.. --without-cgi?

I would go for optionally on, I really dont want to build both the apache
module (p.e.) AND the CGi at the same time. For QA testing this is fine,
but not for production servers.

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[James Moore]

> > 4. The CGI version of PHP is always built and installed.
> 
> I think this should be optional.

Perhaps optionally disabled.. --without-cgi?

James

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[Sascha Schumann]

> 4. The CGI version of PHP is always built and installed.

I think this should be optional.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[Jon Parise]

On Sun, Apr 08, 2001 at 06:21:50PM -0400, Stig Sther Bakken wrote:

> 1. Using --datadir to determine where PEAR PHP files go.  With
>--datadir=/usr/share or --datadir=/usr/share/php, PHP architecture
>independent files go to /usr/share/php, and PEAR's PHP files go to
>/usr/share/php/pear.
> 
>I've added your --with-pear option to override this.
> 
> 2. Using --libdir to determine where extensions go.  With
>--libdir=/usr/lib or --libdir=/usr/lib/php, extensions are
>installed in /usr/lib/php/.  I've also shortened the
> part so "no-debug" and "non-zts" are skipped.  The 
>alternatives are now "20001222", "20001222-zts", "20001222-debug"
>and "20001222-zts-debug".

Both of these sounds good to me.
 
> 3. Using --sysconfdir to determine php.ini path.  The default is now
>$prefix/etc.

Would this be a replacement for --with-config-file-path?
 
> 4. The CGI version of PHP is always built and installed.

I assume that would --bindir, right?
 
> Let me know if you have any problems with these changes.  They should
> make it a lot easier for distributions to build PHP, because we
> conform more to de-facto build conventions (at least on Linux).  Also
> you won't have to re-run configure and make to build the CGI in order
> to run tests, the PEAR installer etc.

I think you're proposed changes cover a lot more (useful) ground than
my simple patch.  Go for it! =)

-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[Stig Sæther Bakken]

[Derick Rethans <[EMAIL PROTECTED]>]
> On 8 Apr 2001, Stig Sæther Bakken wrote:
> 
> > 4. The CGI version of PHP is always built and installed.
> 
> It would be nice if we could disable this, like: --without-cgi

I'll add it.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[Derick Rethans]

On 8 Apr 2001, Stig Sæther Bakken wrote:

> 4. The CGI version of PHP is always built and installed.

It would be nice if we could disable this, like: --without-cgi

Regards,

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands
-


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[Stig Sæther Bakken]

[Jon Parise <[EMAIL PROTECTED]>]
> Does anyone object to the following patch to the PHP configure system?
> 
> It removes the --disable-pear flag in favor of a new --with-pear
> option.  The --with-pair option also allows the specification of the
> PEAR installation directory at compilation time.  For example:
> 
> ./configure --with-pear=/var/www/pear
> 
> ... would install the PEAR hierarchy in /var/www/pear.  The new PEAR
> directory is also added to the default 'include_path', too (that
> behavior isn't really new, but it's a lot more useful now that the
> PEAR location can be specified at compile time).

This patch overlaps with some changes I did on my way home from
ApacheCon.  I haven't committed them yet, but here's a summary:

1. Using --datadir to determine where PEAR PHP files go.  With
   --datadir=/usr/share or --datadir=/usr/share/php, PHP architecture
   independent files go to /usr/share/php, and PEAR's PHP files go to
   /usr/share/php/pear.

   I've added your --with-pear option to override this.

2. Using --libdir to determine where extensions go.  With
   --libdir=/usr/lib or --libdir=/usr/lib/php, extensions are
   installed in /usr/lib/php/.  I've also shortened the
part so "no-debug" and "non-zts" are skipped.  The 
   alternatives are now "20001222", "20001222-zts", "20001222-debug"
   and "20001222-zts-debug".

3. Using --sysconfdir to determine php.ini path.  The default is now
   $prefix/etc.

4. The CGI version of PHP is always built and installed.

Let me know if you have any problems with these changes.  They should
make it a lot easier for distributions to build PHP, because we
conform more to de-facto build conventions (at least on Linux).  Also
you won't have to re-run configure and make to build the CGI in order
to run tests, the PEAR installer etc.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]