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

Tue Oct 3 17:46:43 UTC 2017

2017-10-03 19:34 GMT+02:00 Gunnar Wolf <gwolf at debian.org>:

> 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 pre-built binaries. But it seems shipping
> > pre-built binaries are preferred. It looks to me like a misplaced
> > compromise, but I will follow this advice and ship pre-built binaries
> > next time without building them using npm.
>
> I would strongly prefer to ship pre-built binaries as part of your
> environment in debian/.
>
> I guess the ftp-masters approved the packages you mention as they
> *looked* sane, but not because of a deeper inspection of how they were
> built. I see² you have 17 packages in contrib, out of which 14 are
> node-*. Do they all use npm? Would you appreciate if I took a look at
> them and filed bugs accordingly to ask for ftp-masters' opinion?
>
> ² https://qa.debian.org/developer.php?login=praveen@onenetbeyond.org

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

Jérémy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20171003/54483a88/attachment-0001.html>