[Pkg-javascript-devel] node packages in NEW

[Xavier]

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,...)