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