[Pkg-javascript-devel] node packages in NEW

[Pirate Praveen]

On 2018, സെപ്റ്റംബർ 6 2:15:11 AM IST, Thorsten Alteholz <alteholz at 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.
>
>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.

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.