[Pkg-javascript-devel] node packages in NEW

[Bastien ROUCARIES]

On Thu, Sep 6, 2018 at 10:05 AM Xavier <yadd at debian.org> wrote:
>
> 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.

Do not add in node_modules but in subdirectory see multiple tar dpkg
(like that I have done in node-tap)

> Note that something may be found to verify gpg signatures if any.
>
> Cheers,
> Xavier