<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-10-03 19:34 GMT+02:00 Gunnar Wolf <span dir="ltr"><<a href="mailto:gwolf@debian.org" target="_blank">gwolf@debian.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Pirate Praveen dijo [Tue, Oct 03, 2017 at 12:12:54PM +0530]:<br>
<span class="">> > I am completely with Sean here; I read the following messages, and am<br>
> > happy a better resolution was found. But, FWIW, I'll support Sean's<br>
> > interpretation - Contrib and non-free are *not* places where we can<br>
> > happily breach any bits of policy; they are exclusively for things<br>
> > that cannot be shipped in Debian Main due to their DFSG status.<br>
><br>
> I cannot accept arbitrary interpretations of policy. When build tools<br>
> are not available in main, they cannot go to main, and if the software<br>
> itself is Free Software, it can go to contrib. If you disagree, please<br>
> get the policy clarified. As per the current policy, these packages<br>
> clearly qualified for contrib and these were already accepted by ftp<br>
> masters into the archive. You could go to CTTE and challenge the<br>
> decision of ftp masters.<br>
<br>
</span>Let me quote the Debian Social Contract:<br>
<br>
    Works that do not meet our free software standards<br>
<span class=""><br>
    We acknowledge that some of our users require the use of works that do<br>
    not conform to the Debian Free Software Guidelines. We have created<br>
    "contrib" and "non-free" areas in our archive for these<br>
    works. (...)<br>
<br>
</span>So, contrib is _explicitly_ meant for software that does not meet the<br>
DFSG, not for random stuff that cannot be packaged for convenience or<br>
different issues.<br>
<br>
According to Policy, section 2:<br>
<br>
    Packages in the other archive areas (contrib, non-free) are not<br>
    considered to be part of the Debian distribution, although we<br>
    support their use and provide infrastructure for them (such as our<br>
    bug-tracking system and mailing lists). This Debian Policy Manual<br>
    applies to these packages as well.<br>
<br>
Policy says that all packages in contrib and non-free should be policy<br>
compliant. Further, in 2.2.2:<br>
<br>
    The contrib archive area contains supplemental packages intended<br>
    to work with the Debian distribution, but which require software<br>
    outside of the distribution to either build or function.<br>
<br>
    Every package in contrib must comply with the DFSG.<br>
<br>
    In addition, the packages in contrib<br>
<br>
      • must not be so buggy that we refuse to support them, and<br>
      • must meet all policy requirements presented in this manual.<br>
<br>
For this section, yes, I will be making interpretation - But I hold<br>
that we would be hard-pressed to provide support for something built<br>
with a compiler downloaded at build time. Maybe, as Simon suggests, if<br>
your debian/ includes hashes for the compiler version being<br>
used (and everything it pulls in via npm)... But in that case, it's<br>
probably better to include the tar.gz as part of your debian/<br>
<br>
I *do* take note, however, of:<br>
<span class=""><br>
    Examples of packages which would be included in contrib are:<br>
<br>
    • free packages which require contrib, non-free packages or packages<br>
      which are not in our archive at all for compilation or execution,<br>
      and<br>
</span>    • wrapper packages or other sorts of free accessories for<br>
      non-free programs.<br>
<br>
The first point would seem to cover your use case. However, it's not<br>
necessarily covering (...) compilation or execution via code just<br>
downloaded. It does not cover the equivalent of<br>
"curl <a href="http://exploit.me/stuff" rel="noreferrer" target="_blank">http://exploit.me/stuff</a> | bash"<br>
<span class=""><br>
> Alternatively, those who care enough about the issue can help get these<br>
> tools into main. I have been doing just that over the last years (grunt,<br>
> gulp, babel, jison, webpack to name a few, each with 100s of<br>
> dependencies) so many of the packages currently in main could go there.<br>
> Since the tools are just so many and the people packaging them are<br>
> handful, it will take quite a while for all these tools to be in main<br>
> and I'm going to continue using contrib for these packages until that time.<br>
><br>
> You can also check the record of people who are most vocal over the<br>
> issue (not just in this thread, but in earlier discussions about<br>
> handlebars/dfsg/browserify) and compare who is helping fix the issue and<br>
> who is just talking.<br>
<br>
</span>In this case, I'm clearly in the group of those who are somewhat<br>
vocal, and are not helping your efforts. Well, I did quite a bit of<br>
effort in a related matter with the work I put into packaging Drupal8,<br>
which I dropped in the end¹ precisely due to it not being cleanly<br>
packagable for Debian.<br>
<br>
¹ <a href="http://gwolf.org/node/4087" rel="noreferrer" target="_blank">http://gwolf.org/node/4087</a><br>
<span class=""><br>
> > And, yes, network access during a build... Is a clear no-go. Specially<br>
> > if as a project we are committed to this so neat Reproducible Builds<br>
> > thingy that has made so many among us proud to be part a project where<br>
> > an ages-long problem is finally being tackled - And quite<br>
> > successfully, even!<br>
><br>
> I thought building these things (making sure the source corresponds to<br>
> the distributed binaries), though using tools outside archive, was<br>
> preferred over shipping pre-built binaries. But it seems shipping<br>
> pre-built binaries are preferred. It looks to me like a misplaced<br>
> compromise, but I will follow this advice and ship pre-built binaries<br>
> next time without building them using npm.<br>
<br>
</span>I would strongly prefer to ship pre-built binaries as part of your<br>
environment in debian/.<br>
<br>
I guess the ftp-masters approved the packages you mention as they<br>
*looked* sane, but not because of a deeper inspection of how they were<br>
built. I see² you have 17 packages in contrib, out of which 14 are<br>
node-*. Do they all use npm? Would you appreciate if I took a look at<br>
them and filed bugs accordingly to ask for ftp-masters' opinion?<br>
<br>
² <a href="https://qa.debian.org/developer.php?login=praveen@onenetbeyond.org" rel="noreferrer" target="_blank">https://qa.debian.org/<wbr>developer.php?login=praveen@<wbr>onenetbeyond.org</a></blockquote><div><br></div><div><br></div><div>It might be a good idea to make policy more explicit about downloads during build.</div><div><br></div><div>Jérémy</div><div> </div></div><br></div></div>