FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-05-2008, 04:24 AM
Ben Finney
 
Default FHS location for locally-compiled bytecode (was: FHS location for Python libraries as locally-compiled bytecode)

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 th FHS.

Ben Finney <bignose+hates-spam@benfinney.id.au> writes:

> Josselin Mouette <joss@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'?

--
“Pinky, are you pondering what I'm pondering?” “I think so, |
` Brain, but why would anyone want to see Snow White and the |
_o__) Seven Samurai?” —_Pinky and The Brain_ |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 11:21 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org