[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: poco (updated package)

On Sunday 30 August 2009 16:41:26 Krzysztof Burghardt wrote:
> 2009/5/27 George Danchev <danchev@spnet.net>:
> > The only thing I'm not happy with is the staticaly linked zlib with
> > libpocofoundaton shared object and its debug variant. Can we please fix
> > that to dynamically link with the system provided libz, or is there any
> > reason I'm not aware of to use the zlib version provided by poco's
> > Foundation module?
> Patrick Gansterer prepared patch that make poco use system zlib, and
> link dynamically against it. I included it into updated poco packages:
> http://mentors.debian.net/debian/pool/main/p/poco/poco_1.3.5-1.dsc
> http://mentors.debian.net/debian/pool/main/p/poco-doc/poco-doc_1.3.5-1.dsc
> Regards,

Good news. I have only two points to mention:

* it would be better to explicitly build-depends on zlib1g-dev, instead of 
relying on libssl-dev and libmysqlclient-dev to pull it for us. They will 
hadly drop it in the near future, but explicitly listing our build-depends 
make our intentions clear, robust and predictable; what others need is their 
own business. Agreed? That is the easy one.

* The hard one is that there are slight chances to introduce hard to detect 
ABI drifts when linking to a newer system provided zlib. The comparison chart 
looks as follows:

poco-embedded zlib in poco-1.3.3p1/Foundation/src/zlib.h
version 1.2.3, July 18th, 2005 
( I assume that poco authors, didn't introduce incompatible changes to the 
upstream zlib)

zlib currently provided in sid:
version, October 2nd, 2006

Now, I know that zlib hackers are quite experienced and very careful to 
properly document their version changes, but what I'm brainstorming now is if 
it would be safe to accept that if there is no ABI drift between the above 
zlib versions, we can safely accept that there won't be any ABI drifts in the 
new poco library caused by the linkage with the new zlib. Let me think about 
that for a while, and of course hints from other mentors are welcome.

The good news is that it is only clamfs package which depends on 
libpocofoundation6, which I assume you have already tested it against the new 
poco library and which is under your control, so, if we break it, we can fix it 
easily ;-)

pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>

Reply to: