How should packagers package minizip2 so that it does not conflict with minizip1?

[ryandesign]

Hi, I'm the maintainer of minizip2 in MacPorts. My understanding from reading #333 is that

• minizip2 is not compatible with minizip version 1 as shipped with zlib
• some users may wish to use version 1 and some may wish to use version 2; some software may be compatible with version 1 and other software may be compatible with version 2; therefore, a package manager should provide both versions such that they are simultaneously installable, in other words, they must not install files with the same names to the same locations
• minizip2's build system provides no means to do this
• package managers are therefore expected to patch minizip2's build system extensively to accomplish this

Is that about right? It is what I have been doing, and it is therefore a significantly greater investment of time to update to newer versions of minizip2 (because I have to rewrite our patch each time to adjust to changes you make in your CMakeLists.txt) than it is to update other software.

Could you add an option to the build system to add a "2" suffix to all relevant places? If you were using autotools, for example, I might just run ./configure with --program-suffix=2 but I'm not sure if there's a built-in way to do that with CMake. If you provided an official way to do this, that would also ensure that there is consistency between the different package managers, and then developers of software that uses minizip2 wouldn't have to accommodate such differences.

[nmoinvaz]

• minizip2 tries to maintain backwards compatibility with minizip version 1. If there is a compatibility bug, please file an issue.

To your question about package suffixs, the cmake option MZ_PROJECT_SUFFIX can now be used to optionally append a suffix so that package maintainers can distribute it as minizip2 if they want.

[nmoinvaz]

This library has been renamed minizip-ng and should be packaged as such.