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
