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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Roland Gruber (LAM)
Package: closure-compiler
Version: 20130227+dfsg1-9
Severity: important

Dear Maintainer,

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.


-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages closure-compiler depends on:
ii  default-jre-headless [java6-runtime-headless]    2:1.8-58
ii  java-wrappers                                    0.1.28
ii  libclosure-compiler-java                         20130227+dfsg1-9
ii  openjdk-8-jre-headless [java6-runtime-headless]  8u181-b13-2~deb9u1
ii  oracle-java8-jdk [java6-runtime-headless]        8u77

closure-compiler recommends no packages.

closure-compiler suggests no packages.

-- no debconf information

Reply | Threaded
Open this post in threaded view
|

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

Chris Hofstaedtler
* Roland Gruber <[hidden email]> [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
a great situation, its also not threatening to the packages in
Debian using it, so I'd suggest keeping it for now.
Adrian: you raised the severity, care to lower it until buster is
out (or say some words on why)?

Cheers,
Chris (from the Salzburg BSP)

Reply | Threaded
Open this post in threaded view
|

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

tony mancill
In reply to this post by Roland Gruber (LAM)
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 <[hidden email]> [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...)

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Adrian Bunk-3
On Sun, Apr 07, 2019 at 11:12:30AM -0700, tony mancill wrote:
>...
> Somewhat related, given that closure-compiler upstream releases about
> once a month on average, perhaps it is a candidate for doing Something
> Different.

That's pretty normal for a package, and we aren't even close to the
point where this would matter:

It is by design that stretch ships 2016 versions of packages and
buster ships 2018 versions of packages.

But stretch and buster shipping a 2013 version of a package with more
recent versions means that even the version in stretch is 3 years
older than it could be.

> Maybe a closure-compiler-installer package or something like that?
>...

The main user of the version currently in buster/unstable are reverse
dependencies inside Debian. And some are already blocked by the outdated
version.

closure-compiler-installer would force such packages out of main.

> Cheers,
> tony
> (wearing a Java Team hat...)

cu
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

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

Markus Koschany-2
Am 07.04.19 um 20:36 schrieb Adrian Bunk:

> On Sun, Apr 07, 2019 at 11:12:30AM -0700, tony mancill wrote:
>> ...
>> Somewhat related, given that closure-compiler upstream releases about
>> once a month on average, perhaps it is a candidate for doing Something
>> Different.
>
> That's pretty normal for a package, and we aren't even close to the
> point where this would matter:
>
> It is by design that stretch ships 2016 versions of packages and
> buster ships 2018 versions of packages.
>
> But stretch and buster shipping a 2013 version of a package with more
> recent versions means that even the version in stretch is 3 years
> older than it could be.
What tony wanted to imply is that closure-compiler requires more
maintenance effort than other packages and releases more frequently
which means more changes, more often, more new build-dependencies and
more work. The day is only 24 hours long for all of us. The maintainer
who introduced this package left the team shortly afterwards and tony
just spent some of his time to keep this package in Debian (a real team
effort) because it seems useful for other packages. Those who contribute
nothing to the packaging work, which also means packaging new
build-dependencies and making sure that r-deps continue to work, have
absolutely no right to complain about how up-to-date a package is.

>> Maybe a closure-compiler-installer package or something like that?
>> ...
>
> The main user of the version currently in buster/unstable are reverse
> dependencies inside Debian. And some are already blocked by the outdated
> version.

This is the only reason why this package is still in Debian and
apparently closure-compiler seems to work for those packages, otherwise
the maintainers would have noticed it, I guess? So it is still useful
for its main purpose, being a build-dependency for other packages,
although heavily outdated.

The only positive way forward is to update this package and its
reverse-dependencies. The less positive way is to remove the package
from Debian. Just to be clear, personally I don't mind but the timing is
bad. Maintainers of reverse-dependencies should have had a chance to
contribute a fix or ensure that their packages work without
closure-compiler but it looks to me it never happened. So as long as
those r-deps are useful and work correctly, bug #916145 is not RC.

> closure-compiler-installer would force such packages out of main.

We know that. At least it would give users "something", that's the quick
and dirty approach. IMO this would be the perfect fit for our "bikeshed"
or the currently discussed Debian User Repository idea. However it isn't
implemented yet.





signature.asc (981 bytes) Download Attachment