search

zlib-ng / minizip-ng

Fork of the popular zip manipulation library found in the zlib distribution.
Other
1.22k stars 428 forks source link

rename to something else than minizip #333

Closed illwieckz closed 5 years ago

illwieckz commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

illwieckz commented 5 years ago

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

nmoinvaz commented 5 years ago

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 commented 5 years ago

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

What are the reasons to not prevent confusion?

nmoinvaz commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 https://github.com/Alexpux/MINGW-packages/commit/e1e045dfc9933780ae258a2465d907ebc73c331e#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 commented 5 years ago

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 commented 5 years ago

For reference:

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

Coeur commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

the need for a rename isn't for me

Coeur commented 5 years ago

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 commented 2 years ago

As minizip-ng is not a "drop in" replacement of classical minizip, when I receive a bugfix for "classic minizip", I contribute on zlib ( https://github.com/madler/zlib/pull/590 )

When anyone write to me about my old minizip, I always give information about minizip-ng