FHS location for locally-compiled bytecode

[Toshio Kuratomi]

Ben Finney wrote:
> Toshio Kuratomi <a.badger at gmail.com> writes:
> 
>> Quick question: Why is bytecode considered an alternate binary format?
> 
> It is the form of the program that is executed.
> 
>> it is portable between architectures so it seems like it could also be
>> a candidate for /usr/share.
> 
> Possibly, but the FHS seems to consider "executable" versus
> "non-executable" a distinction worth making. Is '/usr/share' a good
> location for the executable form of a program?
> 
The FHS doesn't specify "executable" in the context of either /usr/lib 
or /usr/share.  With only a few historical exceptions, executables are 
programs which are found under one of the {s,}bin directories (symlinks 
for /usr/lib/sendmail, for instance).

I think byte code falls into a grey area in the FHS... /usr/lib is for:
* "object files, libraries, and internal binraries [...]"
* architecture-dependent data files

/usr/share is for
* architecture independent data files.
* should be shareable among all architecture platforms of a given OS

So there's a few ways that this could be interpreted:

* byte code is architecture independent and can be shared, therefore it 
belongs in /usr/share.
* The byte code is a library of code and therefore belongs under 
%{_libdir} (/usr/lib or /usr/lib64 for
* The FHS authors didn't account for byte code when they wrote this but 
the symmetry of /usr/share and /usr/lib is such that 
architecture-independent-libraries should go in /usr/share.

I believe that the FHS group is discussing an update of the 
specification now and it would be good for someone to bring the subject 
of architecture independent byte code to their attention (they should 
also be aware that not all byte code is architecture independent, or if 
it is, has other baggage -- C#/mono Assemblies fall into this category). 
  They can either close the loophole of byte code being a library but 
architecture independent or make the /usr/share /usr/lib symmetry more 
apparent.

>> A related question, though, would be where Debian puts java bytecode
>> files.
> 
> I'm asking (in this thread) about the FHS, not Debian-specific
> practices.
> 
True.  But this is a grey area.  What the distributions do with other 
byte code is relevant to the discussion.  It might even inform the FHS 
authors of which direction they should clarify things in.  In Fedora we 
have the following:

python: /usr/lib /usr/lib64 split for historical reasons

java: (I believe... least familiar with this) /usr/share/java-X.Y.Z for 
bytecode, /usr/lib/java-X.Y.Z for gcj compiled libraries.

mono: /usr/lib{64} because of some posts by Miguel to Debian lists that 
convinced us that mono byte-code should be considered architecture 
specific due to 1) difficulty of determining if it calls architecture 
specific code in an architecture specifc way, 2) inability to load 
ahead-of-time compiled objects if they are not placed in the same 
directory as their byte-code counterparts.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/distributions/attachments/20080728/917f7892/attachment.pgp