On 2018, സെപ്റ്റംബർ 6 2:15:11 AM IST, Thorsten Alteholz <[email protected]> wrote: >Hi everybody, > >as you already know, there is a big number of node packages waiting in >NEW. Does Debian really need all those packages? > >node packages are rather small and often consist only of a few lines of > >code. From my point of view it is very unlikely that such packages will > >change over time, so their code will remain constant forever. More >likely >upstreams will add new features and pay no attention to backward >compatible APIs. > >In the node ecosystem everything is fine. Their developers use carets >or >tildes as dependency operators and just depened on the version of the >API >they really need. > >In Debian such packages basically create two problems. They bloat the >packages file, which prolongs the process of installing or updating >packages. Further Debian only allows packages with one, the latest, >version in the archive. So uploading packages with the newer API would >make packages unusable, that still depend on the older API. Usually >this >is not recognized and suddenly packages in the archive won't work >anymore. >One could introduce versions within package names, but this would just >multiply the number of node packages. > >To answer my question from above: no, nobody needs these small >packages. > >But of course Debian wants to have packages with a certain >functionality. >Stuff like grunt, d3, babel and npm totally make sense to have. > >So in order to reduce the number of node packages that appear in NEW >and >the archive one might lessen the Debian embedding policy. >What do you think about embedding ... > - small modules that are not going to be changed and contain less than > 50 lines of code (this limit is totally arbitrary) > - put together packages that belong together; I am not sure here, but > wouldn't it be fine to have just one package node-d3 or node-babel >that contains all corresponding modules (though their different >versions > might create problems in keeping track of them)? >In order to not lose track of the installed software, providing >something >like debian/modules.embedded might be nice to have? > >As you know your tools best, can you please create a proposal of how >you >would like to handle maintenance in such a new situation? > >Maybe we can already start by removing node-is-generator-fn, >node-is-npm, >node-is-unc-path and node-isstream and create a wiki page to keep track >of >all node modules that are candidates of being embedded? > >Though I admit it might be a bit demotivating, we would like to REJECT >all >node packages currently in NEW and start as soon as possible with the >new >policy.
I suggest we categorize the packages in NEW and process accordingly. I can help with categorizing it. I propose the following, 1. Simple modules that could be embedded - REJECT. 2. Modules that includes a build step, for example that needs babel, webpack etc. (Modules that will produce a source is missing lintian error). I think those packages would be better in their own package as it will make embedding more complicated to maintain - ACCEPT 3. A module that is a dependency or build dependency of more than 3 packages (arbitrary, could be 5 as well) - ACCEPT -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Pkg-javascript-devel mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
