Ben Finney 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.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 <[EMAIL PROTECTED]> 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.
-Toshio
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Distributions mailing list Distributions@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/distributions
