On Wed, Aug 7, 2013 at 1:20 AM, Petr Vobornik <pvoborni@xxxxxxxxxx> wrote: > Hello, > > Many web apps use an optimization technique where they try to minimize the > number of httpd request by concatenating minified versions into one file. > Example: app uses 20 tiny jQuery plugins. > > Similar use case is when app is using AMD modules and uses only a subset of > modules from a huge lib like Dojo+Dijit+Dojox. Loading whole lib is not an > option - too big. One usually creates a custom build. > > Does the proposal count with these use cases? > > As I read the packaging guidelines [1], one could use the static inclusion > of libraries for it. I don't think it was designed for it, though. I'm not too thrilled with this, but there are only really two solutions here, and they both suck. If you prebuild it, your package becomes a slave to all its dependencies and will have to be updated when even one little one changes, which sucks. If you build it locally, you need to drag in a bunch of dependencies for that, which also sucks. :-( Given that there's no good answer here, I think we should allow this. I tweaked the language in the static inclusion section so this is explicitly permitted and described in the rationale: https://fedoraproject.org/w/index.php?title=User%3APatches%2FPackagingDrafts%2FJavaScript&diff=348406&oldid=348213 > Related Q: What will happen when included library gets updated? The proposal calls for adding versioned virtual provides that track what libraries are included, via a macro that adds the version in the buildroot automatically for you. Thanks to that, we can have a cron job that will bug maintainers to rebuild when one of their statically included dependencies updates. :-) Hopefully with stuff like AMD we can add some RPM magic that adds the virtual Provides automatically, so packagers won't have to track it manually, but compiling during the build process complicates that. If you don't end up installing a package.json or having `require()` calls in the %buildroot there's nothing for an AutoProvReq generator to key off of. :-( Anyway, that's something we'll have to look into in more detail when we get around to packaging that stuff. -T.C. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
