FHS location for locally-compiled bytecode (was: FHS location for Python libraries as locally-compiled bytecode)
a.badger at gmail.com
Mon Jul 28 10:12:42 PDT 2008
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)
>> /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.
>> "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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/distributions/attachments/20080728/3bb5049e/attachment.pgp
More information about the Distributions