On 08/14/2013 07:34 AM, T.C. Hollingsworth wrote:
On Mon, Aug 12, 2013 at 1:05 PM, Robert Marcano
<robert@xxxxxxxxxxxxxxxxx> wrote:
On 08/12/2013 03:23 PM, Robert Marcano wrote:
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
Sorry, I missed this:
"If a JavaScript library can be executed locally or consists purely of
JavaScript code, it must be installed into a subdirectory of %{_jsdir}."
and the Feature says:
"Additionally the following symlinks will be provided:
/usr/share/web-assets/javascript points to /usr/share/javascript"
So non browser JavaScript code will be shared via HTTP?, all those pages are
out of sync that it is difficult to understand what will go to each place
So one possible option that would address your concerns would be to
require every js-foo package to also provide a webjs-foo subpackage or
so that just contains a symlink in /usr/share/web-assets/js to the
appropriate location in /usr/share/javascript.
Or not sharing js, fonts and other assets from a shared directory? I was
checking an application like Roundcube. Patching it requires change a
few files because web apps have no standard way to use those files, It
is easy to find assets files than locating where it is used and test if
you aren't missing something after you patch it. There is need to update
the patches every time a new version make the patch invalid. or check if
a new file is linking to them
What about replace the files on the application directory (/roundcube)
using the webserver related configuration for that like Alias
Alias /roundcube/path_to_jquery/jquery.min.js
/usr/share/javascript/jquery/jquery.min.js
The list of the files should be generated anyways, the Java guidelines
explicitly say that the packager should remove other bundled software
and upload a modified source package (I think this makes easier to say
an application is GPL and not GPL + Apache + BSD... on the spec license
field), probably web application should do the same
We can add rpm macros to generate roundcube-httpd, roundcube-cherokee,
roundcube-nginx, taking the mapping list and generating the equivalent
of the Alias of Apache for those web servers, a lot of the current
packaged applications have a dependency on Apache, and sometimes there
is no need for that
The spec authors have expressed that they have no intentions of
mandating that the packager must use the shared directory, that they can
import the files to the application namespace, so why not make the later
it the standard way?
That would provide a way for dependent packages to express "hey, I
just need you on the server-side" and another way to say "hey, I need
you served over HTTP".
But then, what do we want to do about fonts? Adding *-webfonts
subpackages to every font package would be a lot of work, and makes
that awesome WordPress usecase I mentioned much, much harder. What
about CSS? Do we really need a css-bootstrap for when someone wants
to create a locally run HTML5 application with something like
node-webkit and another webcss-bootstrap for when they really want it
served over HTTP?
It's really a lot of work optimizing for what is an edge case. I'm
not convinced it's necessary, but I'll mention this to FPC during my
meeting with them on Thursday for their input anyway.
-T.C.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
