Ben Finney wrote:
I think you've not only simplified, you've done so in the wrong direction. I'd say instead that “datadir” is for *non-executable* files, and “libdir” for executable.
It depends on what you mean by executable: it is obviously wrong when executable = have the executable bit, so what do you mean by executable ? The arch independent/dependent is much clearer IMHO, and is the vocabulary used by the FHS, AFAIK. It is certainly the one used by the configure script help: --bindir=DIR user executables [EPREFIX/bin] --sbindir=DIR system admin executables [EPREFIX/sbin] --libexecdir=DIR program executables [EPREFIX/libexec] --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] --datarootdir=DIR read-only arch.-independent data root [PREFIX/share] --datadir=DIR read-only architecture-independent data [DATAROOTDIR] --infodir=DIR info documentation [DATAROOTDIR/info] --localedir=DIR locale-dependent data [DATAROOTDIR/locale] --mandir=DIR man documentation [DATAROOTDIR/man] --docdir=DIR documentation root [DATAROOTDIR/doc/libsndfile] --htmldir=DIR html documentation [DOCDIR] --dvidir=DIR dvi documentation [DOCDIR] --pdfdir=DIR pdf documentation [DOCDIR] --psdir=DIR ps documentation [DOCDIR] After all, that's one of the rationale for the FHS: some files are shared by different computers, some are not.
That something is non-executable usually means that it's “architecture-independent”, and traditionally, “executable” has meant “architecture-dependent”,
I don't understand this in the context of python: most python executables are architecture independent (python scripts). For example, /usr/bin/ipython is a python script.
but I don't think that's a necessary distinction here. Viz. the placement of the Python standard library, including mostly architecture-independent executable files, in a “libdir”.
I think we should stop thinking, and start looking :) Here are some files as packaged in the python-numpy Ubuntu package package: /usr/bin/f2py -> (default) python script /usr/bin/f2py2.4 -> 2.4 script /usr/bin/f2py2.4-dbg -> 2.4 debug script ... /usr/lib/python2.4/site-packages/numpy/core/_dotblas.so -> C extension, obviously arch dependent. ... /usr/share/doc/python-numpy/CAPI.txt.gz -> some doc /usr/share/pyshared/numpy/__config__.py -> the python scripts So you have things which are supposed to be called from the shell in bindir, the C extension in libdir, the python code in datadir, the docs in docdir, etc...
That would lead to a misguided attempt to keep ‘foo.py’ separate from the resulting ‘foo.pyc’, which would be far more pain than it's worth AFAICT.
There is no .pyc in a debian package: they are computed at installation time. The .pyc and .so are put in /usr/lib/python2.5/site-package/package-name, but the .py are not (they are softlink to the actual .py, which are in /usr/data/pyshared/package-name). David