/usr/lib vs. /usr/share
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
Re: /usr/lib vs. /usr/share
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 *.pyc _is_ arch-dependant (endian issues, I think) -- --- | Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ | | __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk | --- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Re: /usr/lib vs. /usr/share
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 pgpe6dGOHnreB.pgp Description: PGP signature
Re: /usr/lib vs. /usr/share
Harry Henry Gebel <[EMAIL PROTECTED]> writes: > 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. Yes - the Emacs packages actually work by copying the .el files into a temporary directory and compiling them there. For Python, a better solution would be a modified version of compileall, maybe under a new name. (compileall_debian?) By changing the call to py_compile.compile(), the byte-compiled file can be put in any directory or directories, e.g. both of /usr/lib/python1.5/site-packages/foo.pyc and /usr/lib/python2.1/site-packages/foo.pyc, without the source foo.py file being anywhere in sys.path. >From a few quick tests, it seems that Python 2.0 remembers the path for the source file, so it can still fill in a traceback correctly even when the source isn't in sys.path. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ "Quiet, you'll miss the humorous conclusion."
Re: Status report on python2 transition
Gregor Hoffleit <[EMAIL PROTECTED]> writes: > s/not well-behaved/buggy/: Any binary Python extension package that > doesn't depend on 'python-base >= X.Y, python-base << X.Y+1' is buggy (a > few weeks ago I asked in debian-python for volunteers that filed bug > reports against those packages; don't know about the current status, > though). There's not much we can do about all the Python packages in stable that just depend on python-base (>= 1.5.2-1) though, and I don't see why apt would upgrade to a new version of python-pqueue, for example, just because someone does "apt-get install python-base" after getting their shiny new Debian 3.0 CDs. The only way I can see around this is to scrap python-base and go for python-base-., or for a new name like python-dist-base. Some sort of python-base-x.y would be nice anyway, for maintainers and for the packaging system, so that modules can have a simple depends on a (maybe virtual) package, instead of a versioned depends. (Does dpkg support versioned virtual packages yet?) -- Carey Evans http://home.clear.net.nz/pages/c.evans/ "Quiet, you'll miss the humorous conclusion."
