F20 System Wide Change: Web Assets

[Robert Marcano]

On 08/14/2013 07:34 AM, T.C. Hollingsworth wrote:
> On Mon, Aug 12, 2013 at 1:05 PM, Robert Marcano
> <robert at marcanoonline.com> 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.
>