dumping libzip

[Lubomir I. Ivanov]

On 6 January 2014 22:40, Dirk Hohndel <dirk at hohndel.org> wrote:
> On Mon, 2014-01-06 at 15:28 +0100, Martin Gysel wrote:
>> >>>
>> >>> What's the license this code is under? How much code are we talking
>> >>> about?
>> >>>
>> >>
>> >> it uses zlib license:
>> >> http://en.wikipedia.org/wiki/Zlib_License
>> >
>> > Good - that's GPL compatible.
>> >
>> >> i think we only need the zip.c/h, unzip.c/h, ioapi.c/h from this folder:
>> >> https://github.com/madler/zlib/tree/master/contrib/minizip
>> >
>> > more than 5kloc :-(
>> >
>> > I didn't mind absorbing things like the 320loc sha1 implementation from
>> > Linus. This seems a lot bigger. But then again, figuring out how to use
>> > get this correct as a dependency... I guess I'm mildly biased towards
>> > doing this.
>> >
>> > Linus, what's your take?
>> >
>> > Anyone else with a strong opinion?
>>
>> I quickly skimmed through the ubuntu, fedora and gentoo pkg db:
>> fedora and gentoo seem to provide minizip library and headers [1,2], [3]
>> for ubuntu, I haven't found anything but as said, it was a quick search...
>>
>> If you gonna bundle the minizip files, from a distribution point of
>> view, it would be nice if the bundled code is only used if needed or
>> even requested.
>
> That makes it even harder to do this cleanly. I was going to do suggest
> to simply include this in our sources and include the objects on our
> link line. There is no point in creating yet another shared library
> dependency.
>

i hate to bother dirk and linus further with this one...and i want to
hear more developer opinions with distributions and qmake in regard.

what i can say is that native win32 is already complicated and out of
the question, but possibly the crossbuild will be as well, so if we
decide to use the minizip library we may encounter a lot of distros
that simply don't have it. a simple google search didn't show much
info for osx which leads me to believe minizip "is not there, yet".

also, i recently saw this:
https://github.com/nmoinvaz/minizip
which is basically the most recent user generated repo under the zlib
license and it has zip memory buffer i/o and extras (that we can
avoid), but it seems more active that libzip.

my last suggestion FTM, would be to add a minimal minizip folder in
the subsurface repository and implement a stable, local support for
the weird win32 zip path support that is currently preventing us to
create archives in weird named folders (on win32) and breaking the
eventual, incoming image-per-dive export feature (and others)
properly.

i have patches in mind, but i don't like the idea of sending patches
that will be rejected because of core ideas that were not discussed.
:\

please, if you have an opinion drop that +/- mark. :)

lubomir
--