On Thu, Sep 6, 2018 at 10:05 AM Xavier <y...@debian.org> wrote: > > Le 05/09/2018 à 23:14, Bastien ROUCARIES a écrit : > > 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 > > Hello, > > instead of modifying uscan, we could perhaps build a "proxy" like > https://qa.debian.org/cgi-bin/fakeupstream.cgi which could populate > `node_modules/` directory. Example of such debian/watch: > > version=3 > opts="dversionmangle=s/\+embed\d*$//,repacksuffix=+embed" \ > > https://qa.debian.org/cgi-bin/embednpmjs.cgi?upstream=npmjs/package&deps=npmjs/dependency1,npmjs/dependency2 > \ > .*=package-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz)) > > This CGI could add node_modules/dependency1 and node_modules/dependency2 > in upstream archive.