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 [EMAIL PROTECTED] http://www.debian.org