dumping libzip

[Lubomir I. Ivanov]

On 8 January 2014 00:11, Dirk Hohndel <dirk at hohndel.org> wrote:
> On Tue, 2014-01-07 at 23:32 +0200, Lubomir I. Ivanov wrote:
>> 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. :)
>
> It's a bit early still for us here in Australia... but my reaction is
> this:
>
> a) I don't want to add a dependency to a library that is hard to get for
> people.
>

i guess, that's the whole point of including a library snapshot in our source.
it will improve over libzip, which does not have support for reading
buffers and is broken on win32 paths.

> b) If we add minzip to our sources (which based on the license we can)
> we de-couple ourselves from its upstream. But that may be acceptable.
>

i think it can fit much better.
i see a lot of c++ projects that do that and wrap the minizip around
c++ code and handle zip archives locally not depending on libraries
like libzip.
libzip has requests for buffer i/o made early 2012, and the response
is "Unfortunately, no", which i don't think is serious for such
project.

> c) I don't want to carry around code that isn't used - so what's the
> delta of functionality that it offers versus the functionality that we
> actually need? Or said differently, are there parts that we could easily
> remove while maintaining the functionality that we need? In order to
> make the library smaller and easier to maintain?
>

i think we can.
there is just some basic source code in the lines of "io functions
like fopen", "zipping stuff", "unzipping stuff" and some helper
headers.
we need to include those .o files in our files and simply use the zlib
shared library.

the i/o buffer support from minizip is not part of zlib upstream and
it seems to be only in the minizip upstream.
we technically need that in locations like subsurfacewebservices.cpp
and file.c, but we can still manage to open files instead of buffers.

> d) alternatively, would it make sense to use it ONLY under Windows (so
> that way I can deal with building it locally and create binaries and the
> rest of the OSs can happily keep using their existing libzip)?
>

i'm not sure - too much abstraction IMHO in the case of using one lib
on one OS and one on the other, but it's doable.
i'd much rather favorite a portable self contained, local library that
has a good API and that can be used everywhere with zlib.

lubomir
--

p.s. as i side note (and from the C point of view) the minzip stuff is
a little bit more low-level in comparison to libzip.
i've tested that to some extend, but seeing many projects use it i
don't see a problem.