On 2021-06-24, Theo de Raadt <dera...@openbsd.org> wrote: >> I think the easiest path here is to incorporate the new upstream into a >> port, unless someone is familiar with zlib and can cherrypick out the >> commit(s) that resolve the issue. (I didn't find zlib in ports already.) > > That is completely impossible. It must be in base. There are 3 copies
Yes, things always mess up when different versions of a shared library with the same name and most of the same API exist in base and ports. (This is an ongoing problem with libressl/openssl). Doing this for zlib won't go well. > in base -- userland, kernel, and bootblocks. They must be kept in sync. There's one in perl as well, it's newer already. > It gets updated when things matter. I wasn't aware a change had happened > which matters. The thread makes me unenthusiastic, because I cannot tell > what changed that matters. Updating it is not a trivial effort, because > every bootblock needs testing. I've done it twice... We had various problems in ports, but last time I looked at updating zlib (some years ago) it got derailed into a discussion about largefile stuff and I lost interest. We've been trying to hack around it as best we can in ports. There are probably some cases where we didn't update ports because of it, and probably some where we're using static linked bundled copies (I bet chromium does that). We definitely ran into things wanting the "transparent write" mode and gzclose_r / gzclose_w functions (hacked around e.g. in notmuch). Think I recall seeing some things want gzoffset that probably blocked updating them. I had a quick look on codesearch.debian.net to see if I could figure out what's used but there are bundled copies all over the place so it's near impossible to identify them.
