Le 05/09/2018 à 23:14, Bastien ROUCARIES a écrit :
> On Wed, Sep 5, 2018 at 11:08 PM Bastien ROUCARIES
> <roucaries.bast...@gmail.com> wrote:
>> On Wed, Sep 5, 2018 at 10:50 PM Thorsten Alteholz <alteh...@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


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:

opts="dversionmangle=s/\+embed\d*$//,repacksuffix=+embed" \

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.


Pkg-javascript-devel mailing list

Reply via email to