[Pkg-javascript-devel] Bug#679665: Bug#679665: jquery: build-deps not satisfiable in wheezy

[Jonas Smedegaard]

On 12-07-05 at 06:05pm, Mehdi Dogguy wrote:
> On 05/07/12 17:38, Jonas Smedegaard wrote:
> >On 12-07-05 at 04:34pm, Mehdi Dogguy wrote:
> >>On 30/06/12 17:45, Julien Cristau wrote:
> >>>
> >>>jquery build-depends on node-uglify, which is not in testing.
> >>>This needs to be fixed before release somehow.
> >>>
> >>
> >>A solution might be to use yui-compressor as done prior to version 
> >> 1.7.2+debian-1. yui-compressor seems to be present in testing and 
> >> doesn't have any (severe) bugs currently.
> >
> >No recent severe bugs may have to do with it being inferior to other 
> > compressors and therefore less tested.
> >
> 
> I'm not sure. Looking at the popcon stats, yui-compressor seems more 
> popular than uglifyjs. That doesn't say anything on their quality but 
> makes your argument mostly moot, imho.

Since only YUICompressor exists as a package in Squeeze and Wheezy, I 
find it obvious that YUICompressor ranks highest in popcon.

Compressors are used mostly by JavaScript developers.  Similar to Perl 
developers frequently using CPAN instead of distro-packaged libraries, 
it is my impression that JavaScript developers frequently bypass the 
distro for some of their tools - either compiling them locally, fetching 
readymade binaries, or using online services.  Popcon does not track 
that.

It is my impression that the "hot" compressors at the moment are Google 
Closure Compiler and uglifyjs, with YUICompressor being considered 
clunky and old-fashioned.

I believe popcon stats for yui-compressor relates to those writing their 
own JavaScript code and using YUICompressor with it. They may very 
likely adapt their coding style if what they write breaks, rather than 
chase problems to isolate if their code or the compressor is wrong.

My concern is those writing JavaScript, testing with a _different_ 
compressor, releasing their code, and having it packaged into Debian.
When Debian packaging then recompress using YUICompressor, problems may 
occur that is only discovered much later.

One way to verify my vague impression about compressors used in the wild 
is to look at the header of minified files shipped by upstream but 
unused in Debian packages.  Some of those files are in Debian source 
packages, but some may be stripped from source.



> >Few projects provide regression tests for JavaScript code, so bugs 
> >are seldom caught during build.  So switching compressor now has a 
> >high risk of bugs not getting discovered before release.
> >
> 
> AFAICS, you are testing it using JSHint… so even if you change the 
> compressor, you'll still be running JSHint on it, no? how does it make 
> a difference then? or do you run any other tests? (apologies if I 
> missed something).

Sorry, I was talking about JavaScript packages in general.

Specifically about jquery, it looks to me like JSHint is not an option 
if seeking non-Node solutions:

libjs-jquery/Makefile line 75:
> You must have NodeJS installed in order to test jQuery against JSHint.

I am unaware if jquery tests minified files.

Seems to me that jquery upstream only ever minify using uglifyjs:

libjs-jquery/Makefile line 103:
> You must have NodeJS installed in order to minify jQuery.


> >These are the alternatives I can see:
> >
> >a) Switch to yui-compressor
> 
> >b) Get Nodejs into Wheezy and keep using uglifyjs 

> >c) Provide only uncompressed code
> 
> That would break reverse dependencies though (if there are relying in 
> their code on jquery.min.js).

If we skip installing minified files, then yes it breaks. If we skip 
minifying but still install - i.e. install files that are 0% minified - 
then only download times should be affected.


> >d) Use upstream precompressed code
> >
> 
> Please, no.

There is also the option to switch to slimit.  It is newer code so less 
tested, but seems to borrow patterns from uglifyjs possibly cause it to 
break similarly to uglify instead of at other places.


> >Both a) and b) requires changes to a bunch of packages (list 
> >shortened by some of them already been kicked from Wheezy due to this 
> >issue).
> >
> 
> Why a) requires changes to a bunch of packages? AIUI, we are only 
> talking about jquery here and it already changes some bits of the 
> build system about uglifyjs.

Sorry, I was talking general.


> >Due to the risk of introducing new difficult-to-verify bugs a) is bad 
> >IMO.
> >
> >I prefer b) but someone needs to do the social/political task of 
> >finding an acceptable solution to the namespace clash.  For some 
> >possible solutions someone then needs to implement it technically - 
> >and then arguably it is too late.  So as I see it, b) is only 
> >realistic if someone succeeds in solving the namespace clash problem 
> >without needing much technical work to implement it.
> >
> 
> Personally, I think that fixing the nameclash should not happen during 
> the freeze. ymmv though. After fixing that, one should wonder how to 
> fix the remaining rc-bug (about failed tests) :)

Yeah, if minification is tested at all!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20120705/1bb745d0/attachment.pgp>