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.

Hello,
Is that bug still valid with current version 20130227+dfsg1-10 ?
thanks

* Roland Gruber <post@rolandgruber.de> [190406 16:07]:
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)

Now over 6 years.

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.

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.

cu
Adrian

Hi,

No. Downgrading is the way forward.

If you want to update the package for bullseye, filing an RC bug is not the
way to do it. Joining the team and preparing a new package (after the freeze)
is.

Thanks,

Ivo

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

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.

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.

cu
Adrian

Am 07.04.19 um 20:36 schrieb Adrian Bunk:

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.

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.

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.