On 08/09/2013 06:53 PM, T.C. Hollingsworth wrote:
On Thu, Aug 8, 2013 at 12:22 PM, Robert Marcano
<robert@xxxxxxxxxxxxxxxxx> wrote:
The directory is not called /usr/share/web-javascript, it is called
/usr/share/javascript, and the packaging guidelines draft explicitly says
that the intention is to avoid duplication of libraries, so it is calling to
move all JavaScript reusable code/frameworks/libraries to it, not only
browser based JavaScript, and I quote:
/usr/lib/python2.7 is not called /usr/lib/cpython2.7, because when
most people think "Python", they think "CPython", since that has been
the main implementation of Python for 22 years.
Similarly, /usr/share/javascript is not called
/usr/share/web-javascript, because when most people think
"JavaScript", they think "browser JavaScript", since that has been the
main implementation of JavaScript for 18 years.
There are cool other implementations of Python that work differently,
like PyPy, which uses /usr/lib/pypy. There are cool other
implementations of JavaScript, like Node.js, which uses
/usr/lib/node_modules.
Being pointlessly pedantic in either of these cases would just confuse
users for no benefit.
Debian already uses /usr/share/javascript for this purpose, and it
would be really nice if we both could coordinate on getting some
upstream support for this in certain cases. I'm very strongly -1
against pointless Fedoraisms here.
This is a better explanation of why the use /usr/share/javascript: We
want to be compatible with others distribution that have the legacy idea
that JavaScript is a browser only thing, so in this directory we will
only store JavaScript that run on the browser
"There are also some JavaScript libraries which are intended to be used on
the local system, not served via a web server to a browser. These libraries
clearly have all the standard reasons to avoid duplication."
The preamble before this and the Install Location section afterward
clearly states that there is JavaScript on the system that doesn't
belong it /usr/share/javascript, like GNOME Shell Extensions and
Node.js modules, which live in directories of their own,
This sounds like you think there aren't JavaScript libraries that aren't
tied to an specific runtime, there are
So, where do I put the code for a reusable, non web based, or runtime
dependent JavaScript library? like [1] or [2], these examples doesn't
have Node.js, GNOME Shell, nor GNOME JavaScript applications
dependencies, pure and simple JavaScript. I don't see it on the
"JavaScript Packaging Guidelines". If this is a general "JavaScript
Packaging Guidelines", it should standardize something for them, if it
is "JavaScript for browser Packaging Guidelines" it should be renamed
> but the rest
> of the guidelines still apply to them.
If everything else apply to them, I don't see why a Node.js application
or a GNOME Shell extension need to pull a package named web-assets, it
is a wrong name, plain and simple, and worse If they don't store
anything on /usr/share/javascript because they aren't browser code, why
pull them?
I don't really need to repeat that in every paragraph, do I?
and later it contradict what you say, indicating that they must use
"BuildRequires: web-assets-devel" and
"Requires: web-assets-filesystem"
So, it means all JavaScript, even the used on the local system must depend
of web-assets
web-assets-filesystem contains a handful of directories and symlinks.
It does not drag in Apache configuration.
web-assets-devel defines a few RPM macros. It also does not drag in
Apache configuration.
web-assets-httpd contains the Apache configuration. js-foo libraries
MUST not depend on it, since they could be used with any HTTP daemon.
-T.C.
[1] http://crypto.stanford.edu/sjcl/
[2] http://code.google.com/p/crypto-js/
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
