Source: minizip
Version: 1.1-8
Severity: normal
Hi,
when trying to build a new upstream release of my package vcmi, I
noticed that vcmi was making use of the constant MAXU32 which turned out
to belong be defined by minizip as shipped by vcmi. In an effort to
reduce the amount of embedded code copies in Debian, I had previously
removed the embedded code copy of minizip from vcmi and added a
Build-Depends on libminizip-dev instead.
Unfortunately, src:minizip seems to have diverged from the copy of
minizip as shipped by vcmi, which meant that the constant MAXU32 was not
defined in libminizip-dev and resulted in a FTBFS.
Investigating the problem, I found that apparently, upstream of
src:minizip moved to the contrib directory of src:zlib. That copy of
minizip then also defines MAXU32 as expected by src:vcmi.
I now wonder whether src:minizip should still be around now that
upstream development moved to src:zlib? Should the src:minizip package
not be dropped and should then src:zlib not build libminizip-dev?
It seems that right now we are in a situation where src:minizip ships an
outdated copy of minizip without the hopes of getting further
maintenance. The minizip original tarball is not even advertised for
download anymore on the minizip website.
Moving libminizip-dev to src:zlib would also avoid my problem with
src:vcmi because the minizip copy in src:zlib seems more up-to-date.
What do you think?
Thanks!
cheers, josch
