On Wed, Aug 7, 2013 at 1:20 AM, Petr Vobornik <pvoborni(a)redhat.com> wrote:
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 , 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:
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.