rename to something else than minizip

[illwieckz]

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.

[illwieckz]

Someone just reported:

mz_compat.h doesn't help btw
i couldn't find any references in their includes to the old functions and stuff, so it's basically a completely new package

[nmoinvaz]

You can find an older version here:
https://github.com/nmoinvaz/minizip/tree/1.2

[illwieckz]

you don't understand the issue, I'm not looking for code

[nmoinvaz]

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]

I have no plans to rename the project at this time.

What are the reasons to not prevent confusion?

[nmoinvaz]

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]

Version 2 is different than older versions. 1.2 has a separate branch of its own for applications requiring complete compatibility.

No one asked for this information, this is out of topic.

[illwieckz]

I would recommend reporting the issue you are seeing to mingw and they can address the issue in whatever way they see fit.

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:

• What are the reasons to not prevent third-party packagers being mislead and to not prevent them introducing incompatibilities with third-party projects because of name collision?

[illwieckz]

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]

For reference:

• 2018-09-09: Mingw started to mistakenly replace minizip with this incompatible one, see Alexpux/MINGW-packages@e1e045d
• 2018-09-26: someone reported the issue on mingw, see https://github.com/Alexpux/MINGW-packages/issues/4464
• 2018-10-03: someone reported the issue on xonotic (netradiant) channel
• 2018-10-31: I started to investigate the issue and found what happened
• 2018-11-01: I reported the issue in mingw repository in existing thread
• 2018-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 there

So it looks like the problem is just starting to spread, that's why I'm among the firsts to report it.

[Coeur]

@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]

Yeah, Mingw would have been able to create a minizip2 package the same way distros shipped libpng16 alongside libpng14 at 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]

@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]

the need for a rename isn't for me

[Coeur]

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]

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