[Pkg-javascript-devel] node packages in NEW

[Bastien ROUCARIES]

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