> That's not enough a reason to go with lib/ in Debian IMHO. Have a > look on share/, and you will find that pratically everything > arch-independent goes in there. php itself does this. > > Another hint that Debian doesn't make much of a distinction between > executables and data is the lack of libexec/ > > -- > "One disk to rule them all, One disk to find them. One disk to > bring them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh the thing is I think users may want to share php web apps over the network. and /usr/lib is definetely not the place you should put sth you want to share over a network. /usr/share is meant for that. moreover, php files are not 100% executables. they even do not have their x bits on (nobody uses the mod_cgi anymore for php, do you ?) things taht are in /usr/lib are : - shared libraries (that php files are not) - some executables that the normal user do not have to run himself but that the app internally uses (command launched by wrappers, auth scripts, whatever you want) the only exception to that rule, AFAIK, is python (as already pointed out in this thread) as a php web app packager, I should say that the policy is a real mess, since there is no policy (and I really hope to become a DD soon, in order to work on one with other interested people). IMHO, web apps should be installed in /usr/share/*appname*/ and if your app uses/provides some libraries that othere apps could use, you have to put them into /usr/share/php/*appname*/, since /usr/share/php is in the include_path by default. if your package conflicts with a PEAR one .. well, too bad ;p (when I told you that the lacking of a policy was a real mess ...) -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Attachment:
pgpk2a4vUlrtI.pgp
Description: PGP signature