On Tue, Nov 01, 2016 at 08:50:38PM +0000, Ian Jackson wrote:
> These are tiny packages and there seem to be lots and lots and lots of
> them.
I agree, but I'll play the devil's advocate here for a while:
> Every new source package and binary package is (or causes):
> * An entry in Sources and Packages that everyone, even everyone
> who doesn't use it, needs to download
Apt downloads diffs nowadays, so apart from the first download, updates
are much smaller.
> * A database entry in each of our package management systems
> (the DAK db, the BTS, the PTS/tracker, buildds, etc.)
While there are a lot of node.js packages, it doesn't look to me like
we're packaging more of those than of other packages. If this is too
much for Debian, it means we are already at a limit. Are we really?
> * Processing overhead for every Debian system everywhere on
> the planet, while parsing packaging databases, representing
> package graphs
Same as above.
> * Human effort to review it separately in NEW, ITPs, sponsorship (if
> applicable), etc., which would be easier if aggregated
Really? The nice thing about these packages is that they are small and
mostly have singular, well-defined functions that make them much easier
to review than an aggregated bundle.
> * Corresponding edges in the Debian dependency graphs
See above.
> * Probably several separate git repositories
Again, are we at some limit?
> Our systems are not really set up for so many packages.
People keep saying this over and over but I haven't seen any proof that
Debian is falling apart just from the number of packages it supports. Is
this just something that we say to ratify our desire to block small
packages, or are there numbers to back this up?
> Can you explain why you don't aggregate these into bigger packages,
> for use in Debian ?
Because upstream doesn't aggregate them, and the hole point of the
node.js stuff is apparantly that you can mix&match a lot of small
packages without pulling in useless dependencies.
> I don't think it matters very much exactly what the aggregation
> boundaries are but I think given the size of these packages when I
> looked at a couple upstream, you could profitably put many dozens of
> these tiny libraries into a single .dsc and .deb.
You say the exact boundary doesn't matter but you don't agree with the
boundary currently being chosen. That's not very helpful. Is there a
minimum package size we should have? And why not then just require to
package all of node.js into one big package?
- End of devil's advocate talk -
I agree that it looks like these node.js packages do not map well to
what we in Debian traditionally think of as packages. But that's more
because most other languages out there have decent standard libraries,
and if there are things that are not supported by those, we have
libraries that comprehensively cover certain topics. I think ultimately,
the node.js ecosystem will face some serious problems when they will
also start to feel the pain of exploding dependency graphs, especially
when they will have multiple versions of packages with different
A[BP]Is.
They already have the serious problem that you need to download so many
dependencies just to get something working, that they have to work
around that by distributing "browserified" amalgations of their
dependencies just to make things easy for users.
But still, there is DFSG-complaint software out there that is built with
this stuff and that people clearly want in Debian. Geting that in
Debian's main section seems like the proper thing to do. The pain (real
or imagined) that it's causing should be a learning experience, and I
hope that the node.js community will also draw lessons from it.
Already I've seen that just the ITPs are causing people to review the
packages and finding bugs in them.
Creating larger packages that aggregate multiple node.js packages seems
like a nice idea to bring some order into the chaos (and perhaps reduce
the load on our resources). But seriously, how do we draw the
boundaries? Given the huge number of node.js packages, is there a way to
automate this? How much churn is there and how often do we need to
update those packages? What if node.js package A depends on C version 1,
and package B depends on C version 2, how do we package that in Debian?
It's relatively easy when C is its own package in Debian, then just
create C1 and C2 (like we do with libraries with sonames), but what if C
is in a much larger aggregate package?
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus@debian.org>
Attachment:
signature.asc
Description: Digital signature