Sruthi Chandran writes ("Bug#840937: ITP: node-kind-of -- Get the native type
of a value"):
> * URL : https://github.com/jonschlinkert/kind-of
Pirate Praveen writes ("Bug#842129: ITP: node-path-type -- Check if a path is a
file, directory, or symlink"):
> * URL : https://github.com/sindresorhus/path-type#readme
I picked these two almost at random.
I appreciate you're working hard to package up all this web
application infrastructure. This is an area that Debian is doing
rather poorly in and it is good to see efforts to improve it.
But:
These are tiny packages and there seem to be lots and lots and lots of
them.
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
* A database entry in each of our package management systems
(the DAK db, the BTS, the PTS/tracker, buildds, etc.)
* Processing overhead for every Debian system everywhere on
the planet, while parsing packaging databases, representing
package graphs
* A mail like these ITPs
* Human effort to review it separately in NEW, ITPs, sponsorship (if
applicable), etc., which would be easier if aggregated
* Corresponding edges in the Debian dependency graphs
* Probably several separate git repositories
Our systems are not really set up for so many packages. They were
designed with the assumption that a package would represent a
substantial amount of upstream work, so that the Debian overhead is
modest by comparison.
Can you explain why you don't aggregate these into bigger packages,
for use in Debian ?
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.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
