[Pkg-javascript-devel] Small Node.js packages in NEW

[Sebastiaan Couwenberg]

Hi Thorsten,

Thanks for the feedback.

On 04/04/2015 03:12 PM, Thorsten Alteholz wrote:
> Debian is running on lots of different types of computers ranging from
> high end number crunchers to low end Raspberry PIs or embedded devices.
> While installing/updating a package all of them have to download the
> complete package information and parse it over and over again. This is
> not a problem for high end computers with good network connectivity, but
> low end computers might have a problem.
> As we have seen in the past there are memory constraints or the whole
> process just consumes too much time. I admit that there is lots of room
> for improvement in Debians package handling, but at the moment we just
> have what we have.

Parsing the apt metadata on low-powered hardware is a legitimate
concern. I have experienced this myself with running Debian on embedded
hardware for a firewall system.

> Looking at the popcon statistic of nodejs, the numbers are growing but
> compared with the numbers of dpkg, they are still rather low.
> So I would say the overhead of those nodejs users that need to install a
> few kB of superfluous code is not as bad as the resource consumption of
> all other users.

The disk usage of nodejs module bundle packages is also least of my
concerns. My primary concern is the increased maintenance burden caused
by the one-to-many relationship between the source package and its
various upstreams.

I'm not enthusiastic about trying to solve this problem with a
nodejs-modules package that bundles various small modules. But it seems
the only way to address the metadata concern.

> I don't have a better solution for small packages, but as long as there
> is no improvement in package handling, I think there should be no
> exception. I would still prefer the bundling of several small packages
> into bigger chunks. Isn't git able to handle several upstreams in one
> repository?

Per module upstream branches may have their place in the eventual
solution. I'm thinking about per module watch files and an extensive
get-orig-source script to handle them, these separate tarball can then
be imported to their module specific upstream branch with git-import-orig.

We'll also need a wrapper around uscan that can better report the update
status of the various upstreams. AFAIK it's not possible to replace the
watch file with an executable script like the install files for example
do allow.

Because I can't envision a good solution to the bundling problem, I
strongly prefer not to. Bundling separate upstreams in a single source
package is also very uncommon for other language packages. Should
Node.js really be treated differently?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1