On Fri, Jul 06, 2001 at 12:02:39AM -0700, Kevin Turner wrote: > While we're policy-forming here, shouldn't python*/*.py and > python*/*.pyc go somewhere under /usr/share instead of /usr/lib, as it > is arch-independant? This would be an easy decision, except for those > pesky python .so extensions which are arch-specific and need to be in > /usr/lib. > > "Miscellaneous architecture-independent application-specific static > files and subdirectories should be placed in /usr/share." > -- FHS (v2.1) section 4.4 Also from section 4.4: /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. And from section 4.7: The /usr/share hierarchy is for all read-only architecture independent data files. Much of this data originally lived in /usr (man, doc) or /usr/lib (dict, terminfo, zoneinfo). This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted. Note, however, that /usr/share is generally not intended to be shared by different OSes or by different releases of the same OS. Section 4.4 says that /usr/lib is for libraries; and since it includes Perl 5 modules as libraries I would assume that Python modules count as libraries. This is especially so since (as you point out) not all Python modules are architecture-independent. Also, I think I read that byte-compiled files are not compatible on machines with different byte ordering, so they are also not completely architecture-independent; under normal circumstances these will be created in the same directory as the .py files. I think the key factor here is that anything executable does not appear to be defined as data (anybody here participate in writing these sections so they could comment on if my interpretation is correct?) On the other hand, we could put the .py files in /usr/share if we moved the generated .pyc/.pyo files to /usr/lib (can (should?) compileall be modified to do this automatically?) We would keep sys.path to the standard, and since the .py files would no longer be in sys.path they would no longer be executable and would qualify for /usr/share . I think a system similar to this is how the emacsen allow one Emacs mode package to be used by several Emacs versions. -- Harry Henry Gebel West Dover Hundred, Delaware GPG encrypted email gladly accepted. Key ID: B853FFFE Fingerprint: 15A6 F58D AEED 5680 B41A 61FE 5A5F BB51 B853 FFFE
Attachment:
pgpZ730mio55J.pgp
Description: PGP signature