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

Re: [PHP] Standard placement of PHP libraries?

On Mon, 2 Sep 2002, Steve Langasek wrote:

> > 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)

Oops, I must have missed that discussion.  Is there any particular reason
why it's been a private thing, rather than a public process?

> 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.

Well, Perl uses version-specific directories, and I'm not a Python person,
so I can't comment on that.  But yes, PHP is another scripting language with
most of the same issues, so it makes sense to follow the conventions of
other languages were appropriate.

> > 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.

I'm happy to concede that point.  I'm pretty much a php4-only person, and
don't take an active hand in the larger world of PHP development.

> 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.

I was modelling that from what I'd done with phtml; to reduce possible
conflict (and to provide a migration path from what I'd been doing prior to
my stuff becoming Debianised).  Removing the package name requirement is not
a big issue for me; I'm just a little excessively orderly.  <g>

Could I request that you open up your PHP mini-policy a little?  I'm sure
there are a lot of people interested in this issue; and I for one would like
to see the direction you're heading.

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

Reply to: