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

[PHP] Standard placement of PHP libraries?

I guess this is probably going to turn into a mini-policy discussion, and I
hope so, because I think we need some level of standardisation.

There are several PHP extension libraries packaged for Debian; I guess the
most famous is probably pear, but I maintain one (phtml, used by some other
packages I maintain) and I know there are a couple of others out there, too.
By these libraries I'm not talking about binary modules, I'm talking about
extension libraries written in PHP and available by include('whatever'). 
It's the 'whatever' that I'm mostly interested in discussing for now.

PEAR uses /usr/share/pear, and has an entry in include_path for it.  Hence,
to use any PEAR-shipped function, simply refer to the file by name, relative
to that directory.  Nice, very simple, I highly approve.  Since PEAR holds a
special status, perhaps that should change.

But what about every other PHP extension library out there?  libphp-adodb,
for instance, uses /usr/lib/adodb - in violation of the FHS, I believe,
since PHP scripts shouldn't be architecture specific.  But that's not really
the issue here - the point is, where *should* PHP includes go?

I would like to propose /usr/share/php4 as the place for all scripts
intended to run under php4 (whatever subversion) and intended for inclusion
in other PHP scripts.  All packages would install their inclusion hierarchy
under /usr/share/php4/<package name>, and scripts which wanted to use their
functionality would include('<package name>/include.php').  Naming of
include files, including their extension, would be left to the discretion of
individual maintainers.

The bonus would be that the php4 maintainer would only have to add one
(fairly self-explanatory) directory entry to php4.ini for all time, no other
package would have to worry about modifying php4.ini or getting the user to
do so (BTDT, not much fun).

I can't see any real downsides, as long as everybody plays along.  I'd like
to know of any that anyone can think of.  If there are no objections, and
anyone else thinks it's a worthwhile idea, I'll put my thoughts into a
formal proposal to Policy, for official comment.  I'd rather get shot down
in flames now than get my hopes up.

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

Reply to: