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

[Floris Bruynooghe]

On Mon, Jul 28, 2008 at 10:12:42AM -0700, Toshio Kuratomi wrote:
> Ben Finney wrote:
>> Howdy all,
>>
>> A little while ago on debian-python, we discussed the location of
>> system files that are executable bytecode, created by package
>> management tools at install time, and how to comply with the FHS.
>>
>> Ben Finney writes:
>>
>>> Josselin Mouette <joss at debian.org> writes:
>>>
>>>> As for the FHS argument, I don’t feel strongly for putting
>>>> [compiled Python bytecode] files in /var/lib, it just seemed like
>>>> the most obvious location as this is data that can be regenerated
>>>> at any time. It can be changed very easily if there is consensus
>>>> that another place is better.
>>> FHS 2.3 §4 allows for:
>>>
>>>     /usr/lib<qual> : Alternate format libraries (optional)
>>>
>>>     Purpose
>>>
>>>     /usr/lib<qual> performs the same role as /usr/lib for an alternate
>>>     binary format, except that the symbolic links
>>>     /usr/lib<qual>/sendmail and /usr/lib<qual>/X11 are not required.
>>>     [26]
>>>
>>> "Python source code" versus "compiled Python bytecode" certainly
>>> qualifies as "an alternative binary format", so this seems the most
>>> applicable section of the FHS.
>>>
> 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.


Regards
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org