Repository navigation
rename to something else than minizip #333
Description
Hi, recently some of netradiant contributors using mingw started to complain about them not being able to build anymore.
People started to report such errors:
…/xonotic/netradiant/tools/quake3/common/vfs.c:53:10: fatal error: minizip/unzip.h: No such file or directory
While the toolchain just printed before that:
minizip is installed and detected
mingw-w64-x86_64-minizip is installed
Then people started to report:
there is no unzip.h at all in the msys64 folder
So, that looked weird. I'm not a Windows user myself but I picked a mingw minizip package and at first look it looked weird: the mingw package I got was 2.5.2 (don't know if it's the latest but…) and the latest minizip in Ubuntu (as a random distro example) is 1.1, and this was already looking for trouble.
Then I looked into it and the file layout and just discovered the issue: the mingw's minizip is not minizip anymore. It's another project. I then looked at the .BUILDINFO file and I found the mingw packager adress and the repository url he used, and the README.md in your repository is explicit:
This library is a complete refactoring of the minizip contribution found in the zlib distribution.
The way that yet another minizip was refactored brokes the source compatibility, it's not a drop-in, no one can switch the two minizip and get a software build again. There is a mz_compat.h file I haven not tried yet, perhaps it's easy to port software to use your homonym minizip by rewriting the header paths (I hope it's enough) but even with that, it still requires a manual port which just means it's not a drop-in replacement and can't be called minizip because of that.
So, cross-plarform projects using minizip can't build on mingw anymore since the mingw's minizip is not minizip anymore. Can you rename your project to avoid other distro packagers being misleaded in the future? For sure your project looks great but it is definitely not minizip anymore, and as a software maintainer I hope we will not have to play the “if minizip but mingw else linux” dance into madness…
Thanks in advance.
Activity
illwieckz commentedon Oct 31, 2018
Someone just reported:
Build minizip as separate package
nmoinvaz commentedon Oct 31, 2018
You can find an older version here:
https://github.com/nmoinvaz/minizip/tree/1.2
illwieckz commentedon Oct 31, 2018
you don't understand the issue, I'm not looking for code
nmoinvaz commentedon Oct 31, 2018
I have not misled anybody and I have no plans to rename the project at this time. I am the sole maintainer of the project for many years now. As for compatibility, you are right version 2 is not a drop-in replacement for older version, but most of the older API functions are supported through a compatibility layer.
illwieckz commentedon Oct 31, 2018
What are the reasons to not prevent confusion?
nmoinvaz commentedon Nov 1, 2018
Version 2 is different than older versions. 1.2 has a separate branch of its own for applications requiring complete compatibility. I would recommend reporting the issue you are seeing to mingw and they can address the issue in whatever way they see fit. You are the only one who has recommended renaming the project. I will keep it in mind for the future.
illwieckz commentedon Nov 1, 2018
No one asked for this information, this is out of topic.
illwieckz commentedon Nov 1, 2018
This was done in Alexpux/MINGW-packages@e1e045d#r31128278 and in https://github.com/Alexpux/MINGW-packages/issues/4464 that was linked to this issue before you start to reply.
Can you answer to this simple question:
illwieckz commentedon Nov 1, 2018
Note that by side effect [edit: it looks like the confusion is older on Arch side] this already started to affect Arch Linux too for the mingw cross-compilation feature:
https://aur.archlinux.org/packages/mingw-w64-minizip/
illwieckz commentedon Nov 1, 2018
For reference:
2018-09-09: Mingw started to mistakenly replace minizip with this incompatible one, see Alexpux/MINGW-packages@e1e045d2018-09-26: someone reported the issue on mingw, see https://github.com/Alexpux/MINGW-packages/issues/44642018-10-03: someone reported the issue on xonotic (netradiant) channel2018-10-31: I started to investigate the issue and found what happened2018-11-01: I reported the issue in mingw repository in existing thread2018-11-01: I reported the issue in arch linux, see https://aur.archlinux.org/packages/mingw-w64-minizip/ [edit: it looks like the confusion is older on Arch side]2018-11-01: I reported the issue thereSo it looks like the problem is just starting to spread, that's why I'm among the firsts to report it.
Coeur commentedon Nov 1, 2018
@illwieckz Please make very sure to not use the miniunz.c file from branch 1.2, because it is vulnerable to path-traversal security issues: this was only fixed in branch 2.X.
Well, and the other consideration is that Mingw should learn about Semantic versioning and not blindly update to latest of everything.
illwieckz commentedon Nov 1, 2018
Yeah, Mingw would have been able to create a
minizip2package the same way distros shippedlibpng16alongsidelibpng14at the same time. This is basically all that is needed, nothing more. Mingw just killed every cross-platform projects using minizip. Or, well, since the minizip effort was done to encourage people to not include an obsolete snapshot of minizip in their repository and since cross-platform projects now have to reinclude it, Mingw just somewhat killed the idea of minizip being standalone.That minizip2 looks interesting, but until every distro out there (debian, fedora, arch linux, brew for mac, bsd etc.) ship this minizip2, minizip1 compatibility must be kept otherwise it defeats the whole idea of being “cross platform”. Now those cross platform projects don't build on windows anymore.
Coeur commentedon Nov 1, 2018
@illwieckz if it's just a naming issue, then fork it as https://github.com/illwieckz/minizip2 and ask Mingw to link to your repo instead of nmoinvaz repo.
illwieckz commentedon Nov 1, 2018
the need for a rename isn't for me
Coeur commentedon Nov 1, 2018
Well, then just leave Mingw fix it, it's 100% their issue. :)
[edit: and apparently they did fix it today, https://github.com/Alexpux/MINGW-packages/issues/4464]
gvollant commentedon Jan 4, 2022
As minizip-ng is not a "drop in" replacement of classical minizip, when I receive a bugfix for "classic minizip", I contribute on zlib ( madler/zlib#590 )
When anyone write to me about my old minizip, I always give information about minizip-ng