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

[Toshio Kuratomi]

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.

-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/3bb5049e/attachment.pgp