Pirate Praveen writes ("Re: [Pkg-javascript-devel] Bug#877212: node-d3-color:
B-D npm not available in testing"):
> Lets take the two issues separately.
>
> 1. Whether they are suitable for contrib
I don't think that this is what contrib is for. Contrib exists as
part of our commitment (documented in the Social Contract) to help
users who for one reason or another end up using non-free software or
documentation.
So contrib is for things where there are licensing reasons, why not
all of the dependencies (whether declared formally in the packaging or
not) can be built from source in main.
The most usual cases are (i) something involved has a
noncommercial-use-only licence, or (ii) the thing is a
nonredistributable and what is provided is a package for downloading
it at install-time.
It is true that there are a few other cases which don't fit into the
DFSG category, but they are truly exceptional:
For example, I'm sure we have some packages there containing firmware
whose source code is available, and where in principle Free Software
compilers are available, but where the firmware's cpu architecture is
not a Debian release architecture and not supported even as a build
option by the compilers we are shipping (or perhaps the versions we
are shipping would not work because they are far too new).
That seems superficially similar, but there are some important
differences.
It is one thing to have a few firmware binaries in contrib, when
fixing each individual firmware binary would involve packaging a whole
crossbuilding toolchain. It is very questionable whether it would be
a desirable tradeoff for Debian to maintain, as first-class packages,
a cross toolchain whose only real function is to build some obscure
firmware (and which is hard to use for other purposes).
But in the case of the Javascript ecosystem, it is clearly desirable
that the popular toolchains from the Javascript world should be
available in Debian. Each such Javascript tool enables many dependent
packages, and they also have uses by thdmselves.
And there is a big difference in scale. In the case of the Javascript
tools we are not talking about a handful of obscure exceptions.
And of course the exceptional firmware files I am talking about do
not run on the user's main cpu (by definition). They run in separate
hardware devices, usually with a much stronger security boundary
between them and the user's primary environment.
Often these firmwares are even provided simply as a convenience and
are not even always necessary for the program's operation.
Finally, the firmware files I am talking about are rarely modified
and rebuilt by anyone. Mostly they are handed down as heirlooms.
That's quite unlike the situation with these Javascript packages
and their compilers/transpilers/whatever.
Overall, it seems to me that you are using contrib as a way to get
around what is ultimately simply an engineering or quality problem.
The problem with these packages is not that they have licensing
problems; nor is it that there are other serious fundamental reasons
why distributing their source code, and rebuilding them, is hard.
It's just that the packaging is a lot of work. But skipping on
packaging the build dependencies properly produces packages which
don't meet Debian's minimum quality standards.
So at the very least, I think these problems are RC bugs.
One approach would be to have uploaded the packages to experimental
instead of unstable. I think it's OK to have junk of all sorts of
kinds in experimental.
That does assume, of course, that your plan is for this to be a
temporary situation, and you just want to have somewhere to
share your work while you collaborate in improving this whole area.
If you intend for this situation to persist in the medium term - for
example, if you wanted it to be released alongside buster - then of
course that wouldn't work. But for the reasons I have explained I
don't think that's acceptable.
I'm sorry to be so negative. I appreciate that dealing with all of
this stuff is very hard work and I applaud your determination. But in
this case the resistance you are encountering is justified.
Regards,
Ian.
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
