Le 05/09/2018 à 22:58, Xavier a écrit : > Le 05/09/2018 à 22:45, Thorsten Alteholz a écrit : >> 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. >> >> Thorsten, on behalf of the ftpmasters > > Hello, > > you're right even if it may conflict a little with > https://wiki.debian.org/EmbeddedCodeCopies > > We could also have a different policy for: > - dependency of a end-user software > - development libraries not yet used by any end-user software in main > > In the first case, could follow normal process, and your proposition > could be applied for the second > > Cheers, > Xavier
- More secured for first case (no copy and more easy to follow CVE) - Libraries in the 2nd case: perhaps insert in ITP issue the use level (NPM weekly downloads for example) and/or any other justification (important framework like vue.js,...) -- Pkg-javascript-devel mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
