Bug#916145: closure-compiler: Not working with recent JS code

tony mancill tmancill at debian.org
Sun Apr 7 19:12:30 BST 2019


On Sun, Apr 07, 2019 at 11:16:53AM +0300, Adrian Bunk wrote:
> On Sat, Apr 06, 2019 at 06:13:05PM +0200, Chris Hofstaedtler wrote:
> > * Roland Gruber <post at rolandgruber.de> [190406 16:07]:
> > > the current version is so old that it got incompatible with recent JS code.
> > > E.g. jQuery 3.3.1 cannot be minified as the tool reports parsing errors.
> > > 
> > > Please either update the tool or remove it from the archive. This is now
> > > 5 years in unmaintained state.
> > 
> > I've checked all r-deps of closure-compiler in Debian, and they all
> > build -- datatables-extensions shows some errors in a prebuilt file,
> > but it has done so for a long time, so probably not super relevant.
> > 
> > While I agree that having a 5 year old JS compiler in Debian is not
> 
> Now over 6 years.
> 
> > a great situation, its also not threatening to the packages in
> > Debian using it, so I'd suggest keeping it for now.
> 
> Packages that would require a non-prehistoric version of 
> closure-compiler are already blocked from entering Debian,
> see #843951 and #727529 (since 2013!) as examples.
> 
> Any actual user installing closure-compiler will have a WTF experience 
> when discovering that the new Debian release ships a version that was
> already outdated when the dinosaurs roamed the earth.
> 
> > Adrian: you raised the severity, care to lower it until buster is
> > out (or say some words on why)?
> 
> IMHO the release team adding a buster-ignore tag would be the best way 
> forward here - this would still show up as RC bug for bullseye.

+1 for not orphaning r-build-deps at this point in the release cycle but
forcing the issue at the onset of the bullseye release cycle.

I'm not a user of closure-compiler but have tried to help keep the
package in Debian because it appears to be useful to others.  I agree
that at a certain point, an old package is probably more harmful than a
missing package.  

Packaging the transitive build-deps for closure-compiler is a
non-trivial effort and one that people might easily overlook when they
ask for the latest version.  Since there are plenty of users who want a
newer version, it shouldn't be that hard to get some help with those
build-deps, right?  <wink>

Somewhat related, given that closure-compiler upstream releases about
once a month on average, perhaps it is a candidate for doing Something
Different.  Maybe a closure-compiler-installer package or something like
that?  (Maybe backports would work, but we would have to manage the
transitive dependencies as well.)  

Cheers,
tony 
(wearing a Java Team hat...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-java-maintainers/attachments/20190407/f7bd7426/attachment.sig>


More information about the pkg-java-maintainers mailing list