On Wed, Sep 5, 2018 at 11:08 PM Bastien ROUCARIES <roucaries.bast...@gmail.com> wrote: > > On Wed, Sep 5, 2018 at 10:50 PM Thorsten Alteholz <alteh...@debian.org> 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.
see #899073 for bugs > > > > 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 > > Pkg-javascript-devel@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
