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 <g...@debian.org>
signature.asc
Description: Digital signature