Dear maintainer,

minizip installs its headers in "/usr/include/minizip" and, until
recently, also exported this path in its minizip.pc configuration.

I don't know if intentional or not, but minizip.pc only exports
"/usr/include" now (see diff at the end). This breaks codebases like
Open3D, which tries to include <unzip.h>.

I would prefer for minizip to remain backwards-compatible and revert to
the previous behavior, hence this bug report.


Cheers
Timo


- --- minizip-forky/usr/lib/x86_64-linux-gnu/pkgconfig/minizip.pc 2026-02-16 15:40:58.000000000 +0100
+++ minizip-unstable/usr/lib/x86_64-linux-gnu/pkgconfig/minizip.pc      2026-04-01 23:50:49.000000000 +0200
@@ -1,12 +1,13 @@
 prefix=/usr
 exec_prefix=${prefix}
 libdir=${prefix}/lib/x86_64-linux-gnu
- -includedir=${prefix}/include/minizip
+includedir=${prefix}/include

 Name: minizip
 Description: Minizip zip file manipulation library
 Requires:
- -Version: 1.3.1
+Version: 1.3.2
+License: Zlib
 Libs: -L${libdir} -lminizip
 Libs.private: -lz
 Cflags: -I${includedir}
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmnQsTEACgkQzIxr3RQD
9MoVJw/+MTi7isX2+DB3LrPcSyJmywvVQNg1fSJs3K2w29Zvxqlwcg1dAT5CYkVQ
RaB+HptoFlB3Ob8DviRAKd1ljlDj88jIWWdwPziNR0/567LzMeWWHPzzJlOue/Jc
/f1P2aLXL5WWHT9HfX3jqfGuMyNjyBMqX1nvpAo1dgqEsYX6Zr/RFztjudvDgd9x
vhtBAdTbNt4UD8T6hKKR5ig/YIKKTH9JzpT2ZjIDNUefktulF+uvbOr0UNo13raz
5ymAglwHJ42xKjAyfMKRW6irJAL9UFJl+uRpIho34ZSGSJaDFwip+WCJ+rZ7QrWf
wUs+xum2SQ8iTIMQ9DZQtxlJuPhvkTpz+zlIuBOv1aU9RnlDMZg38Nz9VEjnQ66Y
VFeVemitVducoubCQ/wsQdrnvuUpPPK2stfrwW7x/BRuZP7ZEkSt3zWRrG31h0Bn
8+X54C4tCaDWw2sStjo5bXR4WUIfua5CXBWmwTqZUJbghYln1a5fAeHdJIsnHxeM
nvt0frR2xf1OAndEGx+3/6dy5rd7aJHk3iAoGpueByBaedOLefKcPGUurjO4PkuJ
qKIgNtBbrL+rqBoLZtOquUKfHur/MotW9BPNnL1HK8IfrxjuvHyHQ/W01o3RWUCX
MxgzP+bvz1Lj3oljJG3yGqGpfdGNXQBUQli2vIvYEdSBh7gscqM=
=Wrlp
-----END PGP SIGNATURE-----

Note that this is an upstream change in minizip not a packaging one so I
suspect that this is something that your upstream might want to be aware
of and consider handling.

Note that this is an upstream change in minizip not a packaging one so I
suspect that this is something that your upstream might want to be aware
of and consider handling.

affects 1132628 src:assimp src:collada-dom src:deepin-log-viewer src:ezquake src:fceux src:globalplatform src:gwyddion src:mupen64plus-core src:netradiant src:widelands src:wordgrinder
thanks

Timo Röhling wrote:

Indeed. I'm adding a few more packages. All the ones above contain
this string in their build logs when they are built today:

zip.h: No such file or directory

Mark Brown wrote:

If this is really the case please clone this bug to all the above
packages and explain the maintainers that the packages have to adapt
to this change.

Thanks.

clone 1132628 -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11
reassign -1 src:assimp
reassign -2 src:collada-dom
reassign -3 src:deepin-log-viewer
reassign -4 src:ezquake
reassign -5 src:fceux
reassign -6 src:globalplatform
reassign -7 src:gwyddion
reassign -8 src:mupen64plus-core
reassgin -9 src:netradiant
reassign -10 src:widelands
reassign -11 src:wordgrinder
close 1132628
kthxbye

Yes, this is as I said a deliberate upstream change.  The .pc file has
been changed to not add a -I and require an explicit minizip/ prefix
when including the headers.  See 7e6f0784cc0c3 ("Remedy conflict between
libzip and minizip zip.h.") in upstream git:

    Remedy conflict between libzip and minizip zip.h.

    minizip.pc.in would add @include@/minizip to the include path,
    which would permit simply #include <zip.h> to use minizip. However
    that conflicts with the zip.h from libzip that is put in the root
    include directory. This now does not add /minizip to the include
    path. Now when using pkg-config, #include <minizip/zip.h> must be
    used, where #include <zip.h> would be used for libzip. This is an
    incompatible change with the previous state. Users of minizip and
    pkg-config will need to update their code. #include <unzip.h> will
    need to be updated to #include <minizip/unzip.h> as well.

It's not the sort of thing I'd expect to see customised as part of
packaging.