On Fri, Nov 22, 2024 at 12:29:51PM +0100, Guillem Jover wrote: > [ I'll try to summarize the current discussion and status, what might > be blockers, and a potential incremental way forward. ]
You CCed some people but not me so I only saw this today... > On Wed, 2024-09-25 at 10:48:50 +0200, Mark Brown wrote: > > On Tue, Sep 24, 2024 at 05:45:49PM +0200, Guillem Jover wrote: > > We do OTOH package more software than most distros on more architectures > > so we got a lot more exposure for testing coverage, and the revert would > > involve switching the entire implementation which complicates things a > > bit compared to a risky patch within a package. I'm not totally > > opposed, and if everything goes smoothly we could definitely implement > > it within the timeframe, but it feels like an impactful change to > > introduce now not having considered it sooner. > True, also two months have passed since (that's on me!). At this time, > I'm now not sure whether it is feasible to consider such a switch, even > if there was agreement to do it. As it is, I think there are too many > unknowns! It does seem more safe to offer zlib-ng as an alternative at this point... > I did that, and the current WIP zlib-ng packaging provides now two > builds, one with the new native zng_* API and another (tentatively) > with the compat API/ABI one in libz-dev and libz1 binary packages. > I've tentatively chosen those package names for the compat libraries > to avoid having to go through NEW multiple times (with the assumption > that we'd either go ahead with the switch or the packages could then > simply be dropped). I think this should initially only be uploaded to > experimental, to avoid getting packages built with either zlib or > zlib-ng. But depending on the outcome of this discussion, I think other > (probably better) options would be to perhaps name the compat packages > something like libz-ng-compat*, or drop them completely? The packages could have a different name and support diversion or replacement of the zlib library packages? That'd let people use them if they wanted to. > * I've had concerns both about providing the zlib compat API and the > native zlib-ng API in sid, and then getting a mess of packages > linking against (true) zlib and against (native) zlib-ng, or > packages relying on specific behaviors from either and breaking > when switching from (true) zlib to zlib-ng-compat or vice versa, > for example. What are those concerns? Like Simon says the zlib and zlib-ng APIs are just two separate APIs, they happen to have overlapping functionality but while that might be a bit wasteful it's not obvious that there's any actual problem. > * There were concerns (from Fay) about the output stream changing due > to a potential implementation switch and that affecting external > reproducibility. Personally I think while I can see how this is > annoying for the involved parties, it's part of the "you need > the same tools to generate the same output" premise that we also > assume in Debian. I guess keeping both implementations around > indefinitely, I think, would make this less of an issue, with the > potential drawbacks mentioned in the previous point. Yes, I don't think this should be a blocker - this seems like it's on a similar level to needing to use the same compilers. > * There was a concern (from Mike) about whether the performance gain > at the cost of stream size makes sense, given that the compression > level could be reduced instead to similar effect (?). I'm not sure > how these compare, so it would be interesting to analyze this, > because perhaps that's a less traumatic way to look at it (but that > might require redefining compression level semantics globally in > zlib, or patching users, with neither look very enticing options). > My perception from when I tested it is that the speed up was > significant enough and the size increase not so much, but… In any > case switching to zlib-ng upstream would also imply other benefits, > like (supposedly) a more responsive upstream with more frequent > releases, the new native API, and an implementation other > distributions are switching to. > * Some upstreams have started to use the zlib-ng native API, so > regardless of whether we plan a switch or not, I guess packaging > zlib-ng (w/ or w/ the compat API) might still make sense. Yes, it seems clear that we should package zlib-ng and there's just a question about handling of the compat interface it provides. > After having written the above, and if Mark agrees, I think I'd opt for > uploading zlib-ng to experimental, with the compat packages renamed to > libz-ng-compat* or similar (even if that implies later on another trip > through NEW if we want to perform a full switch), because that might > make it easier to move them to sid as a way less disruptive change, > even if we decide not to switch the default zlib implementation. Yes, that sounds sensible to me.
signature.asc
Description: PGP signature
