dumping libzip

[Dirk Hohndel]

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.

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.

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?

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)?

/D