On Mon, Jun 03, 2002 at 09:01:16AM -0500, Chad Walstrom wrote: > On Sun, Jun 02, 2002 at 11:53:37PM +0200, Jonas Meurer wrote: > > I think debian isn't that good for webservers at the moments. > Depends upon who you talk to. IMHO, Debian makes a great webserver at > the moment. ;-) Considering the alternatives, I still like Debian best. ;) > > One (IMO very good) example is the php include_path. some packages ask > > the user to add /path/to/project_include/ into the php.ini. > IMHO, this is a very Bad Thing(TM). The most elegant solution I've seen > is to add the php_include_path in your Apache configuration via an > Include statement referrencing the software's /etc/<package>/apache.conf > file. Include the /etc/<package>/ directory for customized *.php or > *.inc files as well as the installed share directory > /usr/share/<package>. This is the one feature of PHP that has reduced > my configuration headaches to NIL. Well, the difficulty for packagers is that there's a need to support more than just Apache; we already have a php4-cgi package which can't leverage config settings in apache.conf, and there's talk of supporting other webserver targets for woody+1. So while I agree that Apache makes it wonderfully easy to manage webapps, there needs to be a better solution for the general case. Also, when adding package-specific configuration to apache.conf, you're effectively doing one or two things: you're either modifying the global php settings, which is better done in php.ini itself (or best, not at all); or you're making changes that only benefit a particular package, which is better done with an .htaccess file in that package's directory to provide reasonable encapsulation. > > The best solution would IMO be a global includepath, standard in the > > include_path at php.ini, like /usr/lib/php/, and packages are only > > allowed to make subdirs like /usr/lib/php/package_name. Then there > > wouldn't be this problem any longer with adding to php.ini and so on. > The problem with this approach is that you expose the subdirectories to > ALL of the PHP packages, then. I don't really want my Horde libraries > accessible from phpGroupWare, for example. Just as it doesn't hurt any perl scripts to have /usr/share/perl/5.6.1/Net/Ping.pm on the system if they don't use Net::Ping, it doesn't hurt any PHP scripts to have /usr/share/php/Horde/ if they don't try to include anything from that directory. It only matters if you /do/ have another package that wants to include a Horde class, in which case you want it to be as easy to do so as possible. To provide a consistent environment, it's best to resolve as many namespace conflicts as we can, whether or not all includes are stored in the same directory; and the more packages we have storing their includes in a central directory, the easier it is to find such conflicts so they can be resolved. Of course, there are some PHP includes out there that I'm pretty sure I *don't* want made available in my global include_path, because of how badly written they are; but the easy solution there is to just not install them on any of my servers. ;) Steve Langasek postmodern programmer
Attachment:
pgpjkM_f3rKzp.pgp
Description: PGP signature