custom built versions for JS libs? you're speaking of forks?
Libraries that allow you to combine their modules via web interface 
with all possible modifications. At least this is more of a usecase for
complete web applications than just repacked libraries like rubygem-jquery-rails
For those packaging all modules separately should be enough, but maintaining so
many packages is not fun. Wouldn't than make sense to have one jQuery package split
into many sub-packages for each module?
Also, should all web assets be minified?
----- Original Message -----
From: "Matthias Runge" <mrunge(a)matthias-runge.de>
Sent: Friday, August 29, 2014 1:07:29 PM
Subject: Re: [Fedora-packaging] jquery-ui packaging for use in OpenStack-Dashboard
On 29/08/14 12:29, Josef Stribny wrote:
Putting the versions in the name of packages just doesn't feel
right. Having too many versions of jquery-something is another story.
Yes, I agree. Sadly, I don't see, how we can prevent it; some upstream
is quite good in breaking compatibility. Or in this case, upstream
re-organized file system layout of jquery-ui. A different distribution
prevents us (or OpenStack Dashboard) to use a newer version, because
they have too many other packages relying on old layout.
I'm not blaming Debian here, they did a really good job in unbundling
And that still doesn't solve a custom-built versions of JS libs.
custom built versions for JS libs? you're speaking of forks? At least on
OpenStack Horizon, we're lucky and had the chance to forbid it, although
we had some contributors trying to do "quick fixes" in libraries, when
they were bundled.
packaging mailing list