On Wed, Sep 5, 2018 at 10:50 PM 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.
They are at least what are waiting to be packaging: - browserify - a few package that are needed to regenerate web fonts. > > 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)? I strongly oppose to keep different version. > In order to not lose track of the installed software, providing something > like debian/modules.embedded might be nice to have? i have proposed to do something with uscan in order to simplify the work but I need help on it. The goal is to do something like ,node-bind that embed node-has. The main problem is really updating and getting newer version automatically. With versioned provides we could even keep the best of the world (see node-has or node-tap). Debhelper support will be nice but it is second order problem compared to uscan. > > 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? Maybe, but in the same time could we get speedy review of dependency of browserify ? > > 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. > > Thorsten, on behalf of the ftpmasters > > > -- > Pkg-javascript-devel mailing list > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel -- Pkg-javascript-devel mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
