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 -- Pkg-javascript-devel mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
