Path: csiph.com!news.mixmin.net!news2.arglkargh.de!news.karotte.org!fu-berlin.de!bofh.it!news.nic.it!robomod From: =?UTF-8?B?SsOpcsO0bWUgQ2hhcmFvdWk=?= Newsgroups: linux.debian.maint.java Subject: Re: Bug#1054361: ITP: jruby-jzlib Date: Tue, 24 Oct 2023 17:30:01 +0200 Message-ID: References: X-Mailbox-Line: From debian-java-request@lists.debian.org Tue Oct 24 15:28:36 2023 Old-Return-Path: X-Amavis-Spam-Status: No, score=-8.89 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FVGT_m_MULTI_ODD=0.02, LDO_WHITELIST=-5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -5.5 X-Riseup-User-ID: 48E056354B96302A17194CE2A9A16F130E852FC2FEBBC3945950C8E4EBA5ACA0 MIME-Version: 1.0 Content-Language: fr Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailing-List: archive/latest/23400 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/52eb4de0-0931-430a-8297-e8a65933a0ba@riseup.net Approved: robomod@news.nic.it Lines: 42 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Tue, 24 Oct 2023 11:27:55 -0400 X-Original-Message-ID: <52eb4de0-0931-430a-8297-e8a65933a0ba@riseup.net> X-Original-References: <08e5cc7f-a158-4af5-9fe7-e0a5cf74d8bf@riseup.net> <63f1b611-474a-4541-aea4-750d13fb9c9b@riseup.net> <35ff36e1-dcd6-8817-f963-dcff12a25272@apache.org> Xref: csiph.com linux.debian.maint.java:12716 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