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

[Mehdi Dogguy]

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.

> 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).

> 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).

> d) Use upstream precompressed code
>

Please, no.

> 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.

> 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) :)

Regards,

-- 
Mehdi