Re: FHS location for Python libraries as locally-compiled bytecode
Josselin Mouette <joss@debian.org> writes:
> Le mercredi 21 mai 2008 à 08:59 +1000, Ben Finney a écrit :
> > I don't see that it leads to storing the compiled programs to live
> > under /var/, rather than /usr/ which to my mind is more appropriate
> > for compiled versions of programs installed by the package manager,
> > which don't change except through explicit sysadmin action to change
> > them.
>
> At least python-support is not the only package to do that. On my
> system, the following directories are generated upon package
> installation and will not change in other situations:
> /var/lib/aspell
> /var/lib/defoma
> /var/lib/dictionaries-common
> /var/lib/doc-base
> /var/lib/gconf
> /var/lib/iceweasel
> /var/lib/initramfs-tools
> /var/lib/libxml-sax-perl
> /var/lib/menu-xdg
> /var/lib/python-support
> /var/lib/scrollkeeper
> /var/lib/tex-common
> /var/lib/texmf
> /var/lib/usbutils
> /var/lib/vim
> /var/lib/xml-core
> /var/cache/app-install
> /var/cache/dictionaries-common
> /var/cache/fontconfig
It seems to me that most of these are *not* program executable
libraries, but program data — an admittedly imprecise distinction,
but I think most people here would agree which ones of the above
classify as "executable library code" or "program data".
> You can see that python-support does nothing more than following
> current practice. Therefore the decision of moving these files to
> some place in /usr should probably be made as a whole, not for a
> single package.
I think that, going through the list you post above, python-support
instead sticks out as storing *compiled programs*, rather than
non-executable data, in the directory.
For executable program library code, /usr/lib or /usr/lib<qual> is
recommended by FHS 2.3.
--
\ "Good judgement comes from experience. Experience comes from |
`\ bad judgement." -- Frederick P. Brooks |
_o__) |
Ben Finney
Reply to: