-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
raise skip count in t/001version.t #11
Conversation
Thanks @gregoa -- good catch. I'll create a new release tomorrow with the fix included so you don't need to apply a patch. Out of interest, why do you need to set |
Found some time to do it now. Version 2.209 just uploaded to CPAN (there have bee issues with uploads for the last few days that mean the file should be available at cpan.org soon, but may take a while to pop out on metacpan). Also available on GH at https:/pmqs/Compress-Raw-Lzma/releases/tag/v2.209 Not sure where you source the code from, so you have a few options. Ping me if you need a hand. |
Thanks for taking the patch, and for releasing 2.209! I've now grabbed the tarball from MetaCPAN (which seems to be back on track) and uploaded it to Debian/unstable. As for Ah, now I found an old bug report: https://bugs.debian.org/839987 BTW: The situation is the same for Compress-Raw-Zlib, where we also use Cheers, [0] my commit message is a bit terse: https://salsa.debian.org/perl-team/modules/packages/libcompress-raw-lzma-perl/-/commit/22e9c5e2bd17f87612623dd4aa51a526667ee0af |
Interesting that you allow skew in library versions between compile time & runtime - as an outsider who knows nothing about the the Debian processes it sounds like a problem waiting to happen but I'm sure it must be well controlled. The reason I put the version check in originally was the real problem where I had folk build my code with library version x then run on version y and wonder whey things blew up because of a change in the interface to the library. If I remember correctly I asked the zlib folk to add the compile time & version symbol to allow me to police the check in my code. Regarding the
Not sure your string compare is a safe way to do this test. Ideally you need a runtime version of As you say it feels like a Debian-only issue. My code makes the assumption that compile time library version == runtime library version. Hmmm, would a better option for you to just assume the zlib version is always newer than So the line would change from
to
Anyway, ping if you want to discuss further. BTW, the salsa links all end up in 500 errors. |
On Wed, 21 Feb 2024 14:00:41 -0800, Paul Marquess wrote:
Interesting that you allow skew in library versions between compile
time & runtime - as an outsider who knows nothing about the the
Debian processes it sounds like a problem waiting to happen but I'm
sure it must be well controlled.
Library transitions (i.e. API and/or ABI changes in libraries) are
indeed common, well-understood, and managed (very rare accidents
notwithstanding :))
Basically when e.g. a new zlib version changes ABI, there are some
intermediate steps and then reverse dependencies like Compress::Raw::Zlib
get rebuilt against the new zlib version and will depend on it.
OTOH, if zlib just bumps its version without changing ABI, there's no
need to do anything about Compress::Raw::Zlib; and that's how we get
into the situation we're discussing here :)
The reason I put the version check in originally was the real
problem where I had folk build my code with library version x then
run on version y and wonder whey things blew up because of a change
in the interface to the library.
Right, that was my assumption and that's a support nightmare, and
it's totally understandable from an upstream POV to try and make sure
that versions match. And with `TEST_SKIP_VERSION_CHECK` we can have
both approaches (in most cases except this test):
Regarding the `02zlib.t` change, I assume you are trying to get the
version number at run time in the patch below.
Ack.
Not sure your string compare is a safe way to do this test.
Right, I never felt good about this hack.
As you say it feels like a Debian-only issue. My code makes the
assumption that compile time library version == runtime library
version.
*nod*
Hmmm, would a better option for you to just assume the zlib version
is always newer than `1.2.12` in your patch. The issue with 1.2.12
is a few years old now. I assume you don't have ancient versions of
zlib to contend with in Debian-land?
Oh, indeed, that's a very good point, thanks!
In the meantime enough time (and Debian releases) has (have) passed
that we can ignore older zlibs.
So the line would change from
```
if ($Zlib_ver gt ZLIB_1_2_12_0 || Compress::Raw::Zlib::is_zlibng)
```
to
```
if (1)
```
Thanks, I'll use this!
BTW, the salsa links all end up in 500 errors.
Sorry, right after my message salsa had a maintenance window for
deploying a Gitlab security update, which you seem to have hit :/
Thanks again,
gregor
…--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
|
In Debian we are currently applying the following patch to
Compress-Raw-Lzma.
We thought you might be interested in it too.
The patch is tracked in our Git repository at
https://salsa.debian.org/perl-team/modules/packages/libcompress-raw-lzma-perl/raw/master/debian/patches/skip-new-test.patch
Thanks for considering,
gregor herrmann,
Debian Perl Group