On Fri, Nov 14, 2014 at 08:44:24AM -0500, Donald Stufft wrote: > > > On Nov 13, 2014, at 6:29 PM, Thomas Goirand <z...@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 r...@ringlet.net r...@freebsd.org p.penc...@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: Digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
