[Pkg-javascript-devel] node packages in NEW

Xavier yadd at debian.org
Wed Sep 5 21:58:20 BST 2018


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 information about the Pkg-javascript-devel mailing list