On 2018, സെപ്റ്റംബർ 6 2:15:11 AM IST, Thorsten Alteholz <alteh...@debian.org> 
>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
>upstreams will add new features and pay no attention to backward 
>compatible APIs.
>In the node ecosystem everything is fine. Their developers use carets
>tildes as dependency operators and just depened on the version of the
>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
>is not recognized and suddenly packages in the archive won't work
>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
>But of course Debian wants to have packages with a certain
>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
>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
>    might create problems in keeping track of them)?
>In order to not lose track of the installed software, providing
>like debian/modules.embedded might be nice to have?
>As you know your tools best, can you please create a proposal of how
>would like to handle maintenance in such a new situation?
>Maybe we can already start by removing node-is-generator-fn,
>node-is-unc-path and node-isstream and create a wiki page to keep track
>all node modules that are candidates of being embedded?
>Though I admit it might be a bit demotivating, we would like to REJECT
>node packages currently in NEW and start as soon as possible with the

I suggest we categorize the packages in NEW and process accordingly. I can help 
with categorizing it.

I propose the following,

1. Simple modules that could be embedded - REJECT.
2. Modules that includes a build step, for example that needs babel, webpack 
etc. (Modules that will produce a source is missing lintian error). I think 
those packages would be better in their own package as it will make embedding 
more complicated to maintain - ACCEPT
3. A module that is a dependency or build dependency of more than 3 packages 
(arbitrary, could be 5 as well) - ACCEPT

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Pkg-javascript-devel mailing list

Reply via email to