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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 2023-10-24 à 11 h 02, Emmanuel Bourg a écrit :

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)