On Mon, May 12, 2014 at 12:02:26PM -0700, Jonathan Nieder wrote: > Mark Brown wrote:
> > This doesn't address the issue in the original report: this isn't > > something we should be doing off our own back in Debian, it's something > > that upstream should be doing. The issue isn't that it's hard to build > > shared libraries, the issue is that it's hard to maintain them and so it > > needs to be something that upstream are engaged with. > I'm a little puzzled. Upstream has rules for installing libminizip at > contrib/minizip/Makefile.am. Are you saying that they are buggy or > unmaintained? No, I'm saying that I wasn't aware that this had now been done - I didn't check given that there didn't seem to be anything addressing the content of the discussion in the original report. I do note that this has not been added to the standard Makefile though, that is still static only, so it's not clear to me that the developer (who is mostly a Windows guy) is really aware of this or understands shared libraries on Unix. I'm also not seeing symbol versioning which would be nice but I guess shouldn't be a blocker. > > Please discuss this with upstream. > If you have bug reports in upstream's libminizip support, I'm happy to > work on them upstream. Last time I checked, it Just Worked (tm). > I don't think it would make sense to go upstream and say "Mark Brown > is not happy with how contrib/minizip deals with the shared library. > Discuss" without further details. ;-) Well, figuring out if they realise it is building a shared library and understand the stable ABI requirements that Unix like systems have would be the main thing I guess. The comments in MiniZip64_info.txt about the changes for 64 bit are a bit worrying here but seem to mostly refer to the on disk format rather than the interfaces for users of the library.
signature.asc
Description: Digital signature
