On Mon, Sep 02, 2002 at 07:05:40PM +1000, Matthew Palmer wrote:
> 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?
Adam Conrad and I have begun hammering out a PHP mini-policy (not yet
ready for public consumption) that calls for all PHP classes to be
shipped in /usr/share/php. Yes, PEAR obviously violates this at present
-- so transitioning to the new scheme will require shipping a default
include path that looks in both /usr/share/php and /usr/share/pear.
In discussing this, we concluded that most PHP classes currently use
their own directories as a means of eliminating namespace collisions;
however, this is clearly inappropriate, as it pushes the burden of
resolving collisions on the user, rather than on the maintainer. PHP's
handling of classes should be the same as that of other scripting
languages, such as perl and python.
> 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.
We had ruled out /usr/share/php4, on the grounds that many, if not most,
PHP classes are not specific to php4; some will work with php3, and many
should be forward-compatible with php5.
As far as using /usr/share/php4/<package name>, I'm not aware of any such
requirement for other scripting languages. I think it's reasonable to
allow PHP packages to install their classes in the manner which is most
convenient, and let package conflict resolution take care of the rest.
PEAR already provides us a structure for the namespace, which we ought to
take advantage of.
Steve Langasek
postmodern programmer
Attachment:
pgpf8dvpP5iuU.pgp
Description: PGP signature