Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch
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 http://www.php.net/ 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
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 http://www.php.net/ 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
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 http://www.php.net/ 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
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 http://www.php.net/ 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
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 http://www.php.net/ 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
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 http://www.php.net/ 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
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 http://www.php.net/ 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 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 http://www.php.net/ 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
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 http://www.php.net/ 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
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 http://www.php.net/ 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 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 http://www.php.net/ 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 [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/APIVER. I've also shortened the APIVER 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 Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ 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 [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 Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ 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 [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/APIVER. I've also shortened the APIVER 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 Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ 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
On 8 Apr 2001, Stig Sther 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 http://www.php.net/ 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 [EMAIL PROTECTED]] On 8 Apr 2001, Stig Sther 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 Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ 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
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/APIVER. I've also shortened the APIVER 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 http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
