[Pkg-javascript-devel] node packages in NEW

[Xavier]

Le 05/09/2018 à 23:14, Bastien ROUCARIES a écrit :
> On Wed, Sep 5, 2018 at 11:08 PM Bastien ROUCARIES
> <roucaries.bastien at gmail.com> wrote:
>>
>> On Wed, Sep 5, 2018 at 10:50 PM 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.
>>
>> They are at least what are waiting to be packaging:
>> - browserify
>> - a few package that are needed to regenerate web fonts.
>>>
>>> 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)?
>>
>> I strongly oppose to keep different version.
>>> In order to not lose track of the installed software, providing something
>>> like debian/modules.embedded might be nice to have?
>>
>> i have proposed to do something with uscan in order to simplify the
>> work but I need help on it. The goal is to do something like
>> ,node-bind that embed node-has.
>>
>> The main problem is really updating and getting newer version automatically.
>>
>> With versioned provides we could even keep the best of the world (see
>> node-has or node-tap).
>>
>> Debhelper support will be nice but it is second order problem compared to uscan.
> 
> see #899073 for bugs

Hello,

instead of modifying uscan, we could perhaps build a "proxy" like
https://qa.debian.org/cgi-bin/fakeupstream.cgi which could populate
`node_modules/` directory. Example of such debian/watch:

version=3
opts="dversionmangle=s/\+embed\d*$//,repacksuffix=+embed" \
 https://qa.debian.org/cgi-bin/embednpmjs.cgi?upstream=npmjs/package&deps=npmjs/dependency1,npmjs/dependency2 \
 .*=package-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz))

This CGI could add node_modules/dependency1 and node_modules/dependency2
in upstream archive.
Note that something may be found to verify gpg signatures if any.

Cheers,
Xavier