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

[Markus Koschany]

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.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-java-maintainers/attachments/20190407/2d94a627/attachment-0001.sig>