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
On Tue, Apr 14, 2026 at 12:46:13PM +0200, Santiago Vila wrote:
> Mark Brown wrote:
> > 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.
> 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.
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.
signature.asc
Description: PGP signature
