Open Neustradamus opened 5 years ago
@tehnick: Thanks for your links
The library should probably be added as minizip2
, also see #333.
Can you elaborate what do you mean by that? Is this project being renamed to minizip2?
It is not being renamed. Just like other libraries, that have multiple versions, this one does too. (See https://github.com/nmoinvaz/minizip/issues/333#issuecomment-434904020). Distributions should increment the version number when integrating - maybe something like libminizip28.a
.
Ok, then in Fedora is probably better option to go with the latest supported version in minizip
package, and add *-compat
package with the old unsupported version (rather than minizip{,2}
) - it is more common practice.
The only issue is that the new version is not compatible with previous one; among Fedora packages only qmc2
seems to be linked against new minizip - the rest is compiled against minizip-compat
(8 packages) or bundles the old minizip (7 packages).
@praiskup
add *-compat package with the old unsupported version (rather than minizip{,2}) - it is more common practice.
Hmm, how about sdl
and sdl2
, libidn
and libidn2
, pcre
and pcre2
, tinyxml
and tinyxml2
, etc.?
bundles the old minizip (7 packages)
It is interesting. I thought that in Fedora the usage of embedded copy of such common libraries is not allowed like in Debian.
@tehnick it's not impossible to add minizip2
in Fedora, it's just more common to go with compat for limited period of time (but I have no evidence/statistics for that off hand). We would decide the naming differently be if we planned to support two minizip implementations concurrently, but in this case minizip-compat
should go away (at least we hoped it could happen rather soon - which turns out not to be that trivial...).
I thought that in Fedora the usage of embedded copy of such common libraries is not allowed like in Debian.
Bundling is discouraged practice nowadays in Fedora (not entirely banned), but yes - minizip shouldn't be bundled. It is sort of misunderstanding/bug which will be fixed I believe. Despite the fact that minizip is not really "common library" -- original upstream abandoned it, new upstream is painfully incompatible, and people are used to bundle the old version with various different patches if anything.
minizip shouldn't be bundled
Do you mean exactly including copy of library in program sources? Because problem is not in bundling of library into sources but in using of this embedded copy instead of system library. And this is a different case...
I didn't have to think about "bundling" word definition till now :-), but I can confirm you understand the "problem of bundling" the same way as I do; for "how Fedora understands bundling" see https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries#Requirement_if_you_bundle
Why am I mentioned for Mageia when I don't even know what it is?
Linked to https://github.com/stachenov/quazip (look the link)
Hi, I wanted to let you know that I added minizip2 to MacPorts: https://www.macports.org/ports.php?by=name&substr=minizip&
Added to Homebrew: https://github.com/Homebrew/homebrew-core/commit/dd07f5aa3a056c21a6af3c9279ad06895f93cbfb
$ brew install minizip2
Any news 1 year and 9 months after my ticket?
I am not actively keeping up with the latest news or push for inclusion/updates in any distributions.
One guy can see for Debian 11, the freeze is 2021-01-12?
No reply from Michael Gilbert since my first request.
Next Debian will be here in 2023.
Note: There is 2.10.6 now:
minizip has been removed here, please look history:
But you can see others:
@nmoinvaz: Maybe time to rename this repo, minizip2 no?
There have been requests in the past to do that #333, but the name of the repository is arbitrary in my opinion. When minizip goes to version 3 should I then rename the repository to minizip3?
It is up to package maintainers to determine how they want to incorporate it into a particular package management system. I have already written the source code and provided build system and continuous integration with my own time. I have no interest in really maintaining packages in the various package management systems. I am fine with it being submitted to any package management system so long as it doesn't require changes to the repository. I have even provided a -DMZ_PROJECT_SUFFIX
option for package maintainers who want to have it named minizip2
or minizip3
.
@nmoinvaz: Or minizip-ng :)
We are thinking alike, I have sent @Dead2 an e-mail asking him about it.
Have you tried to contact Michael Gilbert? I have never received a reply since 2 years.
Have you tried to publish directly on Debian?
@tehnick can help, I think.
If not, who can help? I have not a listing to all Debian guys...
What is the solution?
We will be blocked 2 years again? Next Debian "12" will be in 2023.
PS: You can publish too zlib-ng at the same time.
I don't think I have had contact with any of the package maintainers. I could be wrong. If you would like to maintain the package on Debian and need something from me to enable you to do it, let me know. I don't want to maintain the packages myself.
@Neustradamus I do not have time for one more Debian package. Especially for such low-level library which is widely used by different software. (It requires more time for proper maintaining.)
The repository has now been renamed to zlib-ng/minizip-ng. A future release will have the name changes in the README and source code files.
@nmoinvaz: Thanks for this change!
@nmoinvaz Thanks!
OpenMandriva has switched its main zlib and minizip implementations to zlib-ng and minizip-ng. (First stable release with those changes will be 4.3, to be released soon).
@berolinux: Very good news, thanks a lot!
zlib-ng
has been added to iOS as of https://github.com/ProcursusTeam/Procursus/pull/565
minizip-ng
is to be added shortly, (with us deciding wether to add both v1 and v2, or just v2)
Regards:
Update: Procursus
shall only support minizip-ng v2 and above
@demhademha: Thanks a lot for your PRs and the zlib-ng merging.
Hope a perfect PR of minizip-ng soon and a merging by the ProcursusTeam too :)
There have been requests in the past to do that #333, but the name of the repository is arbitrary in my opinion. When minizip goes to version 3 should I then rename the repository to minizip3?
I really suggest do anything possible to never break API and ABI compatibility and continue on same repository. This can save a lot of people which deal with old code on new system from headache. A lot of open source big project (sqlite, curl, original zlib maintain perfect compatibility)
Happy New Year 2022 to all!
@ryandesign: Can you add zlib-ng, like you have done minizip-ng in MacPorts?
@jcapik, @mmuzila: Can you add zlib-ng in Fedora?
@panovotn: Too late to have a minizip and a minizip-ng in Fedora? @praiskup
@pierres, @foutrelis: It is possible to add minizip-ng and zlib-ng in Arch?
@lbartoletti: It is possible to add minizip-ng, zlib and zlib-ng in FreeBSD:
Thanks in advance.
@lbartoletti: It is possible to add minizip-ng, zlib and zlib-ng in FreeBSD:
* https://www.freshports.org/archivers/minizip/
@Neustradamus Hi, I tried last month to replace minizip by minizip-ng, but some ports did not build, even with the option for compatibility. Or I can add it, but without removing minizip legacy.
I'll try to dive back into it and come back later.
@lbartoletti: Thanks for your reply, but please not a replace but an adding of minizip-ng in more current minizip, and a request to add zlib-ng and the orginal zlib.
Some projects use currently the original and some use the ng, the goal is to have not problem. Projects which use minizip or zlib need some changes to use minizip-ng or zlib-ng.
You can see the comment of @gvollant, the original author of MiniZip in this ticket: https://github.com/zlib-ng/minizip-ng/issues/358#issuecomment-841049398
Note: @madler always works on zlib and @gvollant has recently patched MiniZip which is a contrib in original zlib.
I think @gvollant can add a changelog, a readme, etc. here: https://github.com/madler/zlib/tree/master/contrib/minizip.
Original MiniZip place:
zlib master branch:
zlib develop branch:
@panovotn: Too late to have a minizip and a minizip-ng in Fedora? @praiskup
IMO it is never too late, but rather CC @hhorak
Hello all, It's another project, but as original writter of minizip classic legacy, I just want tell that help for makefile / distribution of my other https://github.com/gvollant/smartversion/ (now opensource mit) is welcome. I've just an awful makefile. :-)
One task is also use minizip-ng and zlib-ng in smartversion build
@panovotn: Too late to have a minizip and a minizip-ng in Fedora? @praiskup
IMO it is never too late, but rather CC @hhorak
In Fedora, I see we have minizip-compat-1.2.x and minizip-3.0.x (which is actually minizip-ng). Thus, I'm puzzled a bit and trying to orient myself -- what is the question exactly?
@praiskup, @hhorak: Thanks for your reply! I know but it is not possible to change?
@Neustradamus I've added on my historic page https://www.winimage.com/zLibDll/minizip.html a link to the madler/zlib github and to zlib-ng / minizip-ng . So people which use link from minizip executable get current links.
- minizip-compat-1.2.x to minizip
- minizip-3.0.x to minizip-ng
I see, now I understand better. Fedora is supposed to match upstream naming, so it makes sense at least from this sense. As @praiskup said, it shouldn't be impossible, but we'll need to be careful to not trick users of both too much. I've submitted a tracker for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2037245
@hhorak: Thanks! 🤞
Thanks for your reply, but please not a replace but an adding of minizip-ng in more current minizip, and a request to add zlib-ng and the orginal zlib.
@Neustradamus It's not that simple, since minizip and minzip-ng install the same files, so they conflict with each other.
But, I have successfully built all ports (our package) with minizip-ng or using internal minizip.
I will double-check my patches, ask for an internal revision and I think archivers/zlib-ng and archivers/minizip-ng will be shipped in the next few days on FreeBSD. :tada:
minizip and minzip-ng install the same files, so they conflict with each other
They don't conflict in MacPorts, for example. Per https://github.com/zlib-ng/minizip-ng/discussions/452, we accomplish this by setting -DMZ_PROJECT_SUFFIX=-ng
.
$ port contents minizip{,-ng}
Port minizip contains:
/opt/local/bin/miniunzip
/opt/local/bin/minizip
/opt/local/include/minizip/crypt.h
/opt/local/include/minizip/ioapi.h
/opt/local/include/minizip/mztools.h
/opt/local/include/minizip/unzip.h
/opt/local/include/minizip/zip.h
/opt/local/lib/libminizip.1.dylib
/opt/local/lib/libminizip.a
/opt/local/lib/libminizip.dylib
/opt/local/lib/pkgconfig/minizip.pc
Port minizip-ng contains:
/opt/local/bin/minizip-ng
/opt/local/include/mz.h
/opt/local/include/mz_crypt.h
/opt/local/include/mz_os.h
/opt/local/include/mz_strm.h
/opt/local/include/mz_strm_buf.h
/opt/local/include/mz_strm_bzip.h
/opt/local/include/mz_strm_libcomp.h
/opt/local/include/mz_strm_lzma.h
/opt/local/include/mz_strm_mem.h
/opt/local/include/mz_strm_os.h
/opt/local/include/mz_strm_pkcrypt.h
/opt/local/include/mz_strm_split.h
/opt/local/include/mz_strm_wzaes.h
/opt/local/include/mz_strm_zstd.h
/opt/local/include/mz_zip.h
/opt/local/include/mz_zip_rw.h
/opt/local/lib/cmake/minizip-ng/minizip-ng-config-version.cmake
/opt/local/lib/cmake/minizip-ng/minizip-ng-config.cmake
/opt/local/lib/cmake/minizip-ng/minizip-ng-macports.cmake
/opt/local/lib/cmake/minizip-ng/minizip-ng.cmake
/opt/local/lib/libminizip-ng.3.0.4.dylib
/opt/local/lib/libminizip-ng.3.dylib
/opt/local/lib/libminizip-ng.dylib
/opt/local/lib/pkgconfig/minizip-ng.pc
@ryandesign Thanks, I'll try with -DMZ_PROJECT_SUFFIX=-ng
!
@Neustradamus :heavy_check_mark: for FreeBSD.
We have used -DMZ_PROJECT_SUFFIX=-ng
to avoid the conflicts with minizip. Moreover, we install minizip-ng header to include/minizip-ng
to avoid conflicts with minzip and archivers/libzip
@lbartoletti: Thanks for your work! :)
Now in FreeBSD:
Little last request, it is possible to see to update zlib?
@broonie: We need help to have an update in Debian, there is a very old version of minizip:
And zlib-ng and minizip-ng are missing.
Thanks you, zlib in Debian is up-to-date:
Need an adding:
Others?
minizip-ng (2023-07-28):
Others?
zlib-ng (2023-07-28):
Others?