On Tuesday 18 October 2016 01:51 AM, Josh Triplett wrote: > Andrew Shadura wrote: >> Honestly, I’d like to object to packaging a 31 line script in a separate >> package. > > These are distinct packages, with distinct version numbers, and packages > will need to declare (potentially versioned) dependencies on them. > Packaging numerous libraries in a single source package has downsides as > well, such as larger uploads any time *any* component of the package > changes, or any time a new component gets added. Yes, it is more effort to package them together and it becomes impossible to declare version-ed dependencies. I tried doing this for ruby-jquery-rails and ruby-rails-assets-jquery (ruby-jquery-rails was providing ruby-rails-assets-jquery), but stopped doing it because I could not declare version-ed dependency on ruby-rails-assets-jquery. > I would, in general, object to packages like this *if they're not being > packaged as part of the dependency/build-dependency tree of some > other intended package*, but in general, I think we need to be prepared > to deal with upstreams that have small single-purpose packages. I don't > think we should package the entire node ecosystem, but packaging the > subset of it needed for end-user-targeted packages seems fine. These are dependencies for grunt. https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt > Also, consider the ongoing issue of packaging high-level JavaScript > libraries and frameworks correctly, whose build-dependency toolchains > for processes like minimization/"browserification" have numerous > packages like these in them. If we're going to require the packaging of > all the tools needed to build such libraries, which I absolutely think > we should, then let's not simultaneously put up roadblocks every time > someone tries to do so. > We are crowd funding grunt/browserify packaging http://igg.me/at/debian-browserify
Attachment:
signature.asc
Description: OpenPGP digital signature