[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: php.ini configure package

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: pgp5SUyQjS7U6.pgp
Description: PGP signature

Reply to: