On June 18, Luca - De Whiskey's - De Vitis wrote:
For what concern Debian, the intallation home will still be /usr/lib/zope untill python fully comply FHS[1] (http://python.org/sf/588756). I'll probably move it to /usr/lib/python2.1/site-packages in future, but i'm still not sure.
Well, if you're going to have a policy shoot-out: http://www.debian.org/doc/packaging-manuals/fhs/fhs-4.4.html
/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts.
Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application should be placed within that subdirectory. For example, the perl5 subdirectory for Perl 5 modules and libraries.
Miscellaneous architecture-independent application-specific static files and subdirectories should be placed in /usr/share.
http://www.debian.org/doc/packaging-manuals/fhs/fhs-4.7.html
The /usr/share hierarchy is for all read-only architecture independent data files.
I think most of us would agree that .py(c) files are *libraries* and not *data files*. Data files would be the skeleton instance directory. Perhaps it is a little premature preaching about conformance to the FHS when Zope's package doesn't conform to the Python policy (to which I cannot link because I cannot find a static URL - see /usr/share/doc/python/python-policy.txt.gz).
Debian has choosed to be be strictly compliant to FHS[1], including it in the Debian Packaing Policy.
As demonstrated, Python complies with the FHS. I see no active or archived "serious policy violation" bugs relating to Python's FHS compliance. What is the status of the Python Policy? a. -- Adrian van den Dries avdd@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au