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.
-
|
Sure and for those, they can use an older release of zlib-ng to be compatible with that version. I think chasing the current interface of zlib at the time of development makes sense. FWIW, every recent distro I've used and even illumos has switched to 1.2.12. |
Beta Was this translation helpful? Give feedback.
-
|
I just installed very latest version of Ubuntu (Lunal Lobster) and it says |
Beta Was this translation helpful? Give feedback.
-
|
Fedora 37: 1.2.12: https://distrowatch.com/table.php?distribution=fedora&pkglist=true&version=37#pkglist It seems like Ubuntu is the weird holdout in this case. I'm guessing because canonical has packages or is trying to maintain binary compatibility with something that required the older API. |
Beta Was this translation helpful? Give feedback.
-
|
Out of all the operating systems I have installed in my build cluster, a few use zlib 1.2.11 or older as default, few have some version of zlib-ng as default and the rest have either neither or both zlib and zlib-ng. I don't think any of them has zlib 1.2.13 though... |
Beta Was this translation helpful? Give feedback.
-
|
I don't think 1.2.13 had an API breaking change. From the looks of it, they added a compatibility shim for the old CRC combine function: Probably some outcry from distros that relied on old headers and code that used the old version or from tons of users that are used to zlib having a nearly static API for so long that weren't very careful with how they used it. |
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.
-
|
But it will also drag along any limitations and bugs/regressions from zlib that we might have already fixed in our own API. Our main focus should be compatibility with modern processors and operating systems, not support processors operating systems that most people haven't used in over 10 or 20 years. I have nothing against submitting patches for compatibility issues as long as the patch is clean enough to get accepted, but like I said earlier, some patches depend on if and how zlib will fix the limitation or bug in timely fashion. |
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 have no plans at all about dropping zlib compat mode. Sure, it is a maintenance burden, and it would be nice if the world just converted to the zlib-ng native api, but that is unrealistic. We might in a future release choose to move the compat code out of the main code, so it becomes a bit more of a wrapper to make maintenance easier. But that should not affect the API and users. Bug-for-bug or byte-for-byte identical is something we do not advertise of course (It is much more interesting if we have our own bugs after all 😆). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the reassurance! That's what I needed to hear, appreciate it. I'll bump up working on integration then :) |
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 longvariants 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