[Pkg-javascript-devel] node packages in NEW

[Bastien ROUCARIES]

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.
>
> 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?

Maybe, but in the same time could we get speedy review of dependency
of browserify ?
>
> 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
>
>
> --
> Pkg-javascript-devel mailing list
> Pkg-javascript-devel at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel