Timeline for dropping support for legacy zlib compatibility #1382
Replies: 3 comments 13 replies
-
Eh, I have some mixed feelings about this one. There are a lot of projects that use zlib. It's an uphill battle to replace every call with a zlib-ng call. One of the more compelling features of zlib-ng is that it's a direct, API compatible replacement for zlib. You can usually (with some caveats) LD_PRELOAD the library into the loader and use it everywhere. Your distro provides a slow libpng or chromium? LD_PRELOAD it. Some proprietary package that you have no access to the source to? LD_PRELOAD it (or copy in the shared library to the working path with Windows). Exactly what is the maintenance burden of having the compatibility shims in place? The only notable one I have really noticed is long/size_t/long long type confusion (where a lot of platforms/operating systems define what this type is differently, sometimes depending on the ISA). I think the compatibility mode of zlib-ng is a pretty attractive feature and it'd lose a lot of charm if it lost this. |
Beta Was this translation helpful? Give feedback.
-
Zlib-compatibility is one of the big selling points of zlib-ng in my opinion. With the |
Beta Was this translation helpful? Give feedback.
-
This discussion has got me a bit worried about whether I should invest the time in making Gentoo compatible with zlib-ng (and I'm not the only distribution person who feels this way). I don't think in Gentoo that we're ever going to be in a place where it's acceptable for us to drop legacy zlib binary compatibility (which implies the same behaviour & API compatibility, of course) entirely. If it's on the cards to drop the compatibility side entirely, I don't think it's worth me pursuing. zlib-ng is attractive because it supports both the zlib interface and its own API, allowing people to upgrade to the improved API if desired, while not breaking compatibility with the 2 decades' worth of applications written for zlib. A lot of applications, if written today, wouldn't even use zlib at all. Losing compatibility with those would be a huge loss. I think the value proposition of zlib-ng with 0 legacy compat. becomes pretty different, especially given most people understand zlib-ng as "zlib but with modern cleanups" rather than "zlib with no compatibility" (or "easy to port to"). Now, on the other hand, if you're just talking about bug-for-bug compatibility or similar with the latest zlib release at the time, then that's fine. |
Beta Was this translation helpful? Give feedback.
-
I think we should drop legacy zlib compatibility in zlib-ng 2.2.0, and remove
z_size_t
, replacing allunsigned long
variants of functions permanently with variants usingsize_t
... Keeping the compatibility mode for too long will just complicate maintaining the source code and cause issues especially for Windows builds.Some big projects like GNU have already decided to stop using legacy zlib library for their projects and replace it with alternatives like zstd. Some distributions have replaced legacy zlib with zlib-ng 2.0.x , so we should still support the compatibility mode in 2.1.x series to give them and the developers of the libraries that they distribute enough time to switch to zlib-ng's own API.
This means zlib-ng 2.1.x series must freeze the API early enough so that developers of third-party libraries don't have to resynchronise with API changes and can focus again on developing their own library after the initial switch.
Beta Was this translation helpful? Give feedback.
All reactions