Open Stack

On Fri, Nov 14, 2014 at 08:44:24AM -0500, Donald Stufft wrote:
> 
> > On Nov 13, 2014, at 6:29 PM, Thomas Goirand <zigo at debian.org> wrote:
> > 
> > On 11/14/2014 06:40 AM, Donald Stufft wrote:
[okay, well, actually Thomas Goirand wrote:]
> >>> No, that's for arch independent *things*. Like for example, javascript.
> >>> In Debian, these are going in /usr/share/javascript. Python code used to
> >>> live within /usr/share/pyshared too (but we stopped the symlink forest
> >>> during the Jessie cycle).
[and Donald Stufft replied:]
> >> 
> >> Why does the FHS webpage say differently?
> >> 
> >> From [1]:
> >> 
> >>    The /usr/share hierarchy is for all read-only architecture independent data files.
> > 
> > Which is exactly what I wrote. Oh, maybe it's the "data files" that
> > bothers you? Well, in some ways, javascript can be considered as data
> > files. But let's take another example. PHP, java and perl library files
> > are all stored into /usr/share as well (though surprisingly, ruby is in
> > /usr/lib... but maybe because it also integrates compiled-in .so files).
> 
> Yea it’s the data files part (which is why I added the * * around it in my original message).
> Maybe the FHS uses confuses terminology here but I wouldn’t, and I suspect the NPM maintainers
> feel the same way, classify software that is designed to be executed on the server as “data”.
 
One of the easiest ways to understand why Debian and other systems like
to put architecture-independent interpreted language files (Perl,
Python, JavaScript, etc) in /usr/share instead of /usr/lib actually goes
back way further in the past: back to the time when /usr or parts of
/usr were, well, shared between machines.  The idea is that if there is
a large set of files that will be absolutely, character-for-character,
bit-for-bit identical if installed on different architectures, they may
only be installed once and then reused from there.  Thus, interpreted
source is put in /usr/share, while compiled object files (.a files,
shared object files, shared libraries, Git helper binaries, etc) are put
in /usr/lib, which will be different for each machine.

The Debian package archive takes this one step sideways and says
"arch-independent data should be split into a separate Debian package,
put in /usr/share, and not just installed the same way on any
architecture, but *only exist in a single copy* in the Debian package
archive*".  Thus, pure-Perl, pure-Python, pure-JavaScript (or just
JavaScript, I guess ;)) packages will provide only a single Debian
package that may be installed as-is on any architecture and put files in
/usr/share/{perl,python,javascript,...} that will "just work"
everywhere.

More recently in Debian history, this already-existing split between
arch-independent stuff in /usr/share and arch-dependent stuff in
/usr/lib has been used and even extended once more for multiarch
packages, but that's another story for another day :)

So in short, the idea that anything arch-independent may live in
/usr/share and be used unmodified by any machine on any architecture
kind of makes sense to me personally and to the Debian project as a
whole :)

G'luck,
Peter

-- 
Peter Pentchev  roam at ringlet.net roam at FreeBSD.org p.penchev at storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141114/4d47eca9/attachment.pgp>