Bug#673727: jshint -> non-free, node-grunt -> contrib?
On 26/08/13 14:02, Gustavo Noronha Silva wrote:
> Em Seg, 2013-08-26 às 12:04 +0200, Daniel Pocock escreveu:
>> Could the jshint code just be uploaded to the non-free archive for the
>> moment? Then node-grunt would potentially belong in contrib
>>
>> This would allow developers of other packages to proceed with their
>> efforts. Other packages that build-depend on node-grunt would end up in
>> contrib too, which is not ideal, but it may be better than not having
>> them at all.
> Marcelo and I were poking at grunt to understand how jshint is used, and
> from the looks of it the dependency on jshint is really just for
> internal testing rather than to provide some functionality, so maybe we
> can just disable the jshint bits and package node without the dep.
>
It's not just that: many of the other packages that are built by grunt
have something in their Gruntfile.js to call jshint
Every time somebody packages such a package, they would have to patch
the Gruntfile.js to disable the call to jshint.
jshint is much like lintian: your package may still work if you don't
run it, it is just a QA tool. To use a shell scripting analogy, we
could replace jshint with a symlink to /bin/true and the builds of all
these packages would still succeed, we just wouldn't benefit from the
feedback about any code style issues.
I also notice that grunt-contrib-jshint is a separate upstream source
package. That means the main node-grunt package can be part of Debian
main and only grunt-contrib-jshint needs to go into non-free
To take the idea further, we could make grunt-contrib-jshint into a
virtual package, with two real packages providing it:
grunt-contrib-jshint-only-for-good.deb (in non-free) - packaging of
upstream's work
grunt-contrib-jshint-mock: (in main) - a substitute package that
doesn't do any linting, much like /bin/true doesn't do anything
Developers who want to manually jshint their code and feel they qualify
for the "no evil" clause can then manually install the non-free package,
while pure DFSG builds would work using the mock package.
While it seems sad not to lint all the JavaScript automatically, the
presence of a non-free license means we just have to treat jslint (and
derivatives like jshint) as if they just don't exist at all until such
time that somebody rewrites the code in a DFSG-compliant manner.
Reply to: