On Mon, Jan 10, 2005 at 01:07:36PM -0600, Gunnar Wolf wrote: > Kees Leune dijo [Fri, Jan 07, 2005 at 02:19:18PM +0100]: > > Hi, > > > > I am preparing an ITP for a PHP application that is currently under > > development at my place of employment. While thinking about packaging > > it, I was wondering if there is any PHP application policy or best > > practice. I am now leaning to a setup as follows: > > (...) > > Note that I chose /usr/lib over /usr/share because according to the > > FHS, /usr/share is meant for "all read-only architecture independent > > data files". Although PHP files are read-only and architecture > > indepedent, I consider them as programs. > > Some people have pointed out that other PHP programs go to /usr/share > as well. Just to complement: Perl modules also get installed to > /usr/share if they are not architecture-specific. Python seems not to > be that way, as its standard sys.path does not include /usr/share/*.
On the other hand, python drops .pyc and .pyo files into the same directory as the .py file at python install-time. I'd hazard a guess that it can't find the .pyc and .pyo files if they're in a different place than the .py file they come from. If it can, then I suggest the directory layout's wrong. /usr/share is for package-managed things that can be shared between architectures, as I understand it. This overrides /usr/lib/ being for non-user-executable binaries, but does not seem to override /usr/bin and /usr/sbin being for user-executable binaries, shareable or not. (I suspect it _ought_ to, and if the shareable binaries were big enough and /usr/share/bin was likely to appear in the default path, then noise would be made to make this happen "in the near future") -- ----------------------------------------------------------- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. -----------------------------------------------------------
signature.asc
Description: Digital signature
