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. Note that something may be found to verify gpg signatures if any. Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
