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

Re: [PHP] Placement of PHP programs?



On Fri, 6 Sep 2002, Martin Schulze wrote:

> The best thing would probably to split such a package properly:
> 
> /etc/$package/                for an apache.conf file and package configuration
> /usr/share/$package/root/     for the DocumentRoot for this package
> /usr/share/$package/include/  for additional include files[1]
> /usr/share/$package/data/     for additional data files
> /usr/share/doc/$package/      for documentation
> 
> Since PHP files, include files and data files are not arch-specific,
> static and belong to a package they should be placed inside of the
> /usr directory and not inside the /var directory

I fully agree there.  I assume that the additional include files you speak
of are those only intended for use within the package.  I wouldn't like to
see every PHP package with include files have to add
/usr/share/$package/include to PHP/s include_path.  <g>

> A PHP package should not install or link into /var/www directly since
> that's where the user/admin most likely places his own web pages.  I
> won't feel very happy if random PHP packages would install themselves
> inside of existing web space, especially if they are likely to be used
> with a virtual host on their own.

This is something which has had a bit of debate - whether /var/www is for
the admin or the distribution.  I'm inclined to go with your view - that
it's for the admin, but I can't find any documentation which codifies that
view.

> > But what if people are using a different Web server?  It's possible, so why
> > are we blindly assuming apache?  Should we cater for the default, and anyone
> > doing differently should know enough to fix the problem themselves?  That's
> > a possibility.
> 
> I'd say, include an apache.conf because Apache is the most widely used
> webserver that runs PHP.  You'd probably be very kind if you would
> include configuration snippets for all available web servers, though,
> I wonder if it's worth the effort.

I'm leaning towards the "if you've got another web server, you know how to
configure it", but then there's the maintainers who don't run apache
themselves.  I don't think there's any need to mandate anything, really.

> > And what about where in the docroot we put our program for accessability? 
> 
> In general it should not matter since you should probably use relative
> pathnames within the namespace of the particular package.  Hence if it
> is installed in /, the files are referenced as /foo.php, however, if
> they're mapped into the web server as /bar/, then all files will be
> referenced as /bar/foo.php.

But the apache config will, by default, stick it somewhere in the
webserver's space.  Should we be asking a question in Debconf ("where do you
want to access this from using your web browser?"), pick something and use
it, or don't do anything and let the user sort it out.  I'm a fan of option
1, with a default of the package name.

> Since the user needs to map the package into his own namespace, either
> in his main web space in /var/www or into one of his virtual hosts,
> but that's really an issue of the user.  I don't think a package could
> find out all possibilities of Apache configurations and (virtual)
> hosts configurations to add itself into the proper one.  Hence, I'd
> say, leave it to the admin.

Certainly we don't want to hardwire anything, but your average newbie admin
is going to want it to work straight out of the box.


-- 
Matthew Palmer, Debian Developer
mpalmer@debian.org     http://www.debian.org



Reply to: