Per:
https://bugzilla.redhat.com/show_bug.cgi?id=1424609
https://bugzilla.redhat.com/show_bug.cgi?id=985344

Looking at file readme, I'm curious how maintenance of contrib files works in zlib. I tried to contact both original authors of minizip, and none of them seem to be able to help merging those PRs in.

Since there are no huge requirements on quality of code under ./contrib (unsupported code),
could we simply merge those fixes in? Or could we drop the ./minizip subdirectory entirely
as a clear note that we should move to forks?

@madler since this fix is probably used on many distributions (RedHat I guess and Gentoo for sure), could be incorporated to next release?

Thank you

@madler ping

We're also deleting the crypt.h header file manually when packaging zlib for Arch Linux. @madler can this please be included? :)

@gvollant: Can you look?

Gentle ping

I'm not seeing what the issue is here. There is no problem with z_crc_t, as it is defined in zlib.h. I just tried compiling minizip with all combinations of NOCRYPT and NOUNCRYPT, and it works fine. (After removing the forced definition of NOUNCRYPT in unzip.c.)

I don't understand what "People did mistakenly or unintentionally include crypt.h before" means.

One issue this solves is that crypt.h conflicts with the GNU crypt.h. I've just run into this causing a problem with a C++ project that use Python.h (which has a #include <crypt.h>) but also has a (transitive) dependency on minizip, thus pulling in an -I/path/to/minizip and the wrong header is resolved.

Guess this doesn't matter so much now with 7e6f078?