Russ Allbery <rra@debian.org> writes: ... >> The web ecosystem is still changing rapidly, with WebAssembly coming >> soon, so probably things are going to look very different for the >> Debian buster development cycle. > > Indeed. > > I do think the Node community takes this too far, with way too many > micropackages that should just be part of the standard library. But, > well, it works for them, and it's not a totally unreasonable way to handle > things. I think Debian should find ways to stay flexible and adjust and > incorporate those sorts of philosophies about the reusable unit of > code. As an interested observer, this flood of packages certainly is a bit surprising (although it is very nice to see the underlying problem of missing build tools being addressed). However, having seen the case of node-os-homedir, it strikes me that there is one very good reason to package things individually. It focuses our disdain where it is deserved. If this were in a combined package, and if the broken code was only spotted after passing NEW, then it would be much more effort to eject it. It would almost certainly be argued, as you'll see here: https://github.com/sindresorhus/os-homedir/issues/4 that the code should never be reached in the real world, so nothing to worry about. That however glosses over the fact that we have downstreams doing many bizarre things, and that someone might manage to reach the hopeless code, and thus suffer foreseeable bugs. As it is, we can just say "no thanks" to that specific package, with the result that the packages that depend upon os-homedir get patched to use something newer (if they're to be packaged), to the benefit of the whole node.js community. On the other hand, I suspect that a lot of this code is really not fit to be packaged yet ... or at least not for stable. Take a look at: https://github.com/sindresorhus/repeating/blob/master/index.js This a trivial bit of code, which will make those of us not in the node.js community boggle, but let's forget about that for a moment. Let's say that it had been packaged in May this year, at version 2.0.1 and that would make it's way into Stretch, and thus be preserved in aspic until the end of the LTS support. In June, version 3.0.0 was released, which reverses the order of the two parameters. I presume that much of the software that uses that function will rapidly switch to the new ordering, and would have thus found our 2.0.1 package worse than useless. This is not really criticism of the 'repeating' library itself, but just an instance where a slight change of timing seems likely to have resulted in poor outcomes, if we let this sort of software into stable. That said, the decision to swap the parameters is apparently justified by the fact that 99% of the usage of this function is to repeat an empty string: https://github.com/sindresorhus/repeating/issues/6 which makes me realise that I really have no clue whatsoever what they think they are doing in the land of node.js Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Attachment:
signature.asc
Description: PGP signature