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

Ben Finney ben+freedesktop at benfinney.id.au
Sun Jul 27 22:38:08 PDT 2008


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.
> 
> Would '/usr/libcompiled/' or '/usr/libbytecode/' be an appropriate
> hierarchy to place locally-compiled bytecode for package-installed
> software?
> 
> > What I do feel strongly for, is putting them in a directory that
> > remains separate from /usr/lib/python2.X.
> 
> Thanks for your convincing argument, I'm now in support of this much.

This issue applies just as much to other packages with byte-compiled
languages (e.g. Elisp bytecode, Java bytecode, etc.) so I'm raising it
on debian-devel.

I'm strongly of the position that files which should not be changing
(except at package-install time) should not be anywhere under '/var',
as per the FHS definition of that hierarchy.

These files aren't "regenerated at any time", instead they are
generated once and are then executable bytecode for the installed
program that should not change until the package itself changes.

Instead, program bytecode compiled on package installation should be
under '/usr/lib<qual>' as per FHS 2.3 §4. I agree with Josselin that
they don't belong in '/usr/lib' itself.

I don't know what a good name for such a "compiled program bytecode"
hierarchy would be; my reading of FHS 2.3 doesn't suggest a good name.
Perhaps '/usr/libbytecode'?

-- 
 \              “Whatever you do will be insignificant, but it is very |
  `\                        important that you do it.” —Mahatma Gandhi |
_o__)                                                                  |
Ben Finney



More information about the Distributions mailing list