Fwd: Bug#1054361: ITP: jruby-jzlib

[Jérôme Charaoui]

Hello,

I've prepared the jruby-jzlib package, but I'm uncertain about the
relationship it should have with jzlib.

Since the module itself is still using the same "com.jcraft" namespace,
I'm thinking of using a Conflicts: and Provides: on libjzlib-java.

You can check out the package here:
https://salsa.debian.org/lavamind/jruby-jzlib

Thanks!

-- Jérôme


-------- Message transféré --------
Sujet : Bug#1054361: ITP: jruby-jzlib
Date de renvoi : Sun, 22 Oct 2023 14:48:02 +0000
De (renvoi) : Jérôme Charaoui <jer...@riseup.net>
Pour (renvoi) : debian-b...@lists.debian.org
Copie (renvoi) : debian...@lists.debian.org, wn...@debian.org
Date : Sun, 22 Oct 2023 10:45:27 -0400
De : Jérôme Charaoui <jer...@riseup.net>
Répondre à : Jérôme Charaoui <jer...@riseup.net>, 105...@bugs.debian.org
Pour : Debian Bug Tracking System <sub...@bugs.debian.org>

Package: wnpp
Severity: wishlist
Owner: Jérôme Charaoui <jer...@riseup.net>
X-Debbugs-Cc: debian...@lists.debian.org

Package name : jruby-jzlib
Version : 1.1.5
Upstream author : ym...@jcraft.com, JCraft,Inc.
Upstream contact : Charles Oliver Nutter <hea...@headius.com>
URL : https://github.com/jruby/jzlib
License : BSD-3-clause
Programming Lang : Java
Description : JRuby's fork of the jzlib pure-Java zlib library

JZlib is a re-implementation of zlib in pure Java. This version is a
fork of com.jcraft:jzlib with additional improvements for the JRuby
environment.

This is part of an effort to improve the JRuby build chain in Debian.

Thanks,

-- Jerome

[Emmanuel Bourg]

Hi Jérôme,

Le 24/10/2023 à 15:18, Jérôme Charaoui a écrit :

> I've prepared the jruby-jzlib package, but I'm uncertain about the
> relationship it should have with jzlib.
>
> Since the module itself is still using the same "com.jcraft" namespace,
> I'm thinking of using a Conflicts: and Provides: on libjzlib-java.

No that's not necessary, because the libjzlib-java and
libjruby-jzlib-java packages do not conflict at the filesystem level.
The Conflicts field doesn't cover classpath conflicts.

> You can check out the package here:
> https://salsa.debian.org/lavamind/jruby-jzlib

I got a quick look at the jzlib fork [1] and there are very few changes
compared to the original project, it just adds a JPMS auto module name.
We could simply patch our existing jzlib package instead of introducing
a new one. On the jruby side, that would mean patching the Maven
coordinates of jzlib (org.jruby:jzlib -> com.jcraft:jzlib).

Emmanuel Bourg

[1] https://github.com/jruby/jzlib

[Jérôme Charaoui]

Hi Emmanuel,

Le 2023-10-24 à 10 h 02, Emmanuel Bourg a écrit :
> Hi Jérôme,
>
> Le 24/10/2023 à 15:18, Jérôme Charaoui a écrit :
>
>> I've prepared the jruby-jzlib package, but I'm uncertain about the
>> relationship it should have with jzlib.
>>
>> Since the module itself is still using the same "com.jcraft"
>> namespace, I'm thinking of using a Conflicts: and Provides: on
>> libjzlib-java.
>
> No that's not necessary, because the libjzlib-java and
> libjruby-jzlib-java packages do not conflict at the filesystem level.
> The Conflicts field doesn't cover classpath conflicts.

Right, my thinking was to use the same path usj/jzlib.jar to signal the
classpath conflict. Otherwise, we can install it to usj/jruby-jzlib.jar
and not make the packages conflict, but I'm not sure what would happen
if both were installed at the same time, at the JVM-level.

>> You can check out the package here:
>> https://salsa.debian.org/lavamind/jruby-jzlib
>
> I got a quick look at the jzlib fork [1] and there are very few changes
> compared to the original project, it just adds a JPMS auto module name.
> We could simply patch our existing jzlib package instead of introducing
> a new one. On the jruby side, that would mean patching the Maven
> coordinates of jzlib (org.jruby:jzlib -> com.jcraft:jzlib).

There are some (small) code changes as well, here is a pkgdiff report:
https://paste.lib3.net/lavamind/2023-10-24-gBV6KdXXUJ4R0DlxXjjnjz0RmA9OCJ6goNYKux5c03M/changes_report.html

In addition, I believe there may be more substantive changes in the
future since there are zlib-related bugs reported against JRuby which
may lead to further changes in jruby-jzlib, see
https://github.com/jruby/jruby/issues/6613

Thanks,

-- Jérôme

[Emmanuel Bourg]

Le 24/10/2023 à 16:28, Jérôme Charaoui a écrit :

> Right, my thinking was to use the same path usj/jzlib.jar to signal the
> classpath conflict. Otherwise, we can install it to usj/jruby-jzlib.jar
> and not make the packages conflict, but I'm not sure what would happen
> if both were installed at the same time, at the JVM-level.

If both jars are loaded in the classpath the JVM will randomly resolve
the classes from the 2 files, that may lead to runtime errors if the two
implementations are not binary compatible.

> There are some (small) code changes as well, here is a pkgdiff report:
> https://paste.lib3.net/lavamind/2023-10-24-gBV6KdXXUJ4R0DlxXjjnjz0RmA9OCJ6goNYKux5c03M/changes_report.html

Looking at the changes :

* DeflaterOutputStream.java: exception message changed
* GZIPHeader.java: private 'time' variable removed
* GZIPInputStream.java: getModifiedTime method added (typo fix)
* Inflate.java: call a setter instead of setting the variable directly
* ZStream.java: comment change

The only notable change is the addition of getModifiedTime(), we can add
it to the existing package.

> In addition, I believe there may be more substantive changes in the
> future since there are zlib-related bugs reported against JRuby which
> may lead to further changes in jruby-jzlib, see
> https://github.com/jruby/jruby/issues/6613

Good point. If the code diverges significantly an independent package is
perfectly justified then.

Emmanuel Bourg

[Jérôme Charaoui]

Alright, thanks for the analysis! I'll patch GZIPInputStream.java in the
existing jzlib package to add getModifiedTime(), and I'll keep an eye on
jruby-jzlib and upload it if/when it diverges more from jzlib.

-- Jérôme