Re: [Pkg-rust-maintainers] Upcoming switches to zlib-rs
Fabian Grünbichler wrote:
> On Sun, Apr 27, 2025, at 8:29 PM, Josh Triplett wrote:
>> [Ccing Folkert, one of the upstream maintainers of zlib-rs.]
>
> switching the Debian Rust list over to the discussion one which sees
> less traffic and is more likely to be actively read :)
Good call.
>> Several upstream Rust crates are switching to zlib-rs, including cargo,
>> rustup, and gitoxide. I wanted to give you as much advance notice as
>> possible, since it looks like zlib-rs isn't packaged in Debian yet. (I'd
>> expect it to be relatively easy to package; it shouldn't have any
>> unusual requirements compared to other Rust crates.) This will also
>> require flate2 1.1.1.
>
> better late than never - zlib-rs (and libz-rs-sys and libz-rs-sys-cdylib)
> are waiting for review in the Debian NEW queue :)
Thanks! That'll end up being a dependency of many upcoming crates.
Once that's accepted from NEW, hopefully you can drop the various patches in
debcargo-conf disabling zlib-rs (at least flate2 and zip, possibly rustup
though I didn't find the patch).
>> This came about because zlib-rs 0.5.0 made a change to no longer export
>> the C zlib symbols by default, so using zlib-rs no longer requires
>> carefully making sure that nothing else in the address space uses a
>> different zlib library; there won't be any symbol conflicts.
>
> related - since the initial upload is just going to experimental anyway,
> this can easily be changed still. is there any upstream guidance about
> packaging the cdylib w.r.t. prefixing symbols or not? are there prominent
> non-Rust projects using zlib-rs already that might have a preference?
>
> I opted for shipping it unprefixed for now, with the headers in a separate
> dir (since they should be compatible anyway that likely makes no difference).
> it should be possible to use the resulting library as a drop-in replacement,
> but it means not being able to mix libz and libz_rs in a single project.
It's a tradeoff, similar to the one that zlib-ng would have to deal with. But I
think I'd recommend prefixed, for now. (Folkert, thoughts on the below?)
If you use prefixed symbols, libraries and applications using the zlib C
interface can make *independent* decisions to use zlib-rs, one-by-one, without
having to worry what else in their address space is using zlib.
If you use unprefixed symbols, everything in an address space has to switch
over at once to avoid conflicts, which is a substantial coordination issue.
*Eventually*, in an ideal world, there'd be a package that Provides zlib1g and
libz1, and installs zlib-rs (with unprefixed symbols) as libz.so.1 . And
further in the future, that package could become the default. That's a ways
off, though.
In the meantime, if you install a prefixed version and appropriate headers,
people can decide on a case-by-case basis to rebuild their packages against it
for performance. That also provides proof points showing that it works for
those various packages, offering more confidence to support eventual systemwide
usage.
>> I would not expect this to become an issue until after the upcoming
>> stable release. (It'll come up for new versions of rustc-web, though.)
>
> it's not an issue for rustc(-web or not) since those packages vendor
> their Rust dependencies.
Ah, fair enough.
>> Hopefully this will go smoothly; please reach out if there are any
>> issues.
>
> thanks for reaching out/the heads up, and sorry for the delay in
> getting back and handling it!
No problem! Let me know if there are any issues.
- Josh Triplett
Reply to: