FHS location for locally-compiled bytecode (was: FHS location for Python libraries as locally-compiled bytecode)

[Toshio Kuratomi]

Floris Bruynooghe wrote:
> On Mon, Jul 28, 2008 at 10:12:42AM -0700, Toshio Kuratomi wrote:

>> Quick question: Why is bytecode considered an alternate binary format?  
>> it is portable between architectures so it seems like it could also be a  
>> candidate for /usr/share.  A related question, though, would be where  
>> Debian puts java bytecode files.  If those are in /usr/lib, then python  
>> byte code would fall under the same hierarchy.
> 
> Hmm, not sure if Java is comparable.  The issue with Python is that
> the source code can be run by the interpreter too, with Java this is
> not the case.  Possibly better to compare it to Lisp?
> 
> The architecture independed remark is a good point.  I'd be interested
> to know where other distributions tend to put these bytecode files
> currently.  In Python's case Debian seems to make a mess currently by
> spreading it out in /usr/lib/pythonX.Y (next to the source, this used
> to be the de-facto standard a while ago) and /var/lib/python-support.
> What's annoying about this IMHO is that Debian's sys.path is different
> from a "normal" one.
> 
In Fedora we have multilib which makes things interesting on x86_64. 
I'll talk about that case since the x86 case is pretty easy to see if 
you understand the x86_64 case.

Some python modules are pure python.  These live in /usr/lib/pythonX.Y. 
  It's source + .pyc + .pyo.  (We include the .pyo files for a few 
reasons which I can dig up if other distributions don't do that.)  We've 
talked internally about moving these modules to /usr/share/pythonX.Y 
before but it's generally been seen as not upstream, not conventional, 
and generally a lot of work in testing and QA that will just confuse users.

Python modules that are not pure python end up in /usr/lib64/pythonX.Y. 
  Once again it's any .py source + .pyc + .pyo (and this time) + .so.

There's a few rules we have to follow surrounding this: notably, python 
does not merge directories when searching for modules, so a module that 
installs a foo.compiledbar and a foo.purepybaz can't be split to install 
partially in /usr/lib and partially in /usr/lib64.  The whole thing goes 
to /usr/lib64.  Our python knows about both directories internally. 
distutils.get_python_lib(plat_specific=0) returns /usr/lib while 
distutils.get_python_lib(plat_specific=1) returns /usr/lib64.

On x86 or other non-multilib systems, both sets of directories get 
folded into /usr/lib/.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/distributions/attachments/20080728/6706f751/attachment.pgp