Thomas Klausner wrote:
> On Mon, Apr 17, 2006 at 10:54:48AM -0400, Johnny Lam wrote:
>> I expect lots of breakage on this one.  How well does the new libpng 
>> support the deprecated API?  I couldn't find any documentation on how to 
>> use the deprecated functions.  It looks like maybe we can just pass 
>> -DPNG_INTERNAL to the compiler to make it use the deprecated functions, 
>> but I haven't tested this yet.  Since CUPS is breaking, it looks like 
>> this support isn't so good.
> 
> If I understand it correctly, the deprecated functions are just
> not in the library at all. Bernd?

Maybe the deprecated functions are no longer in the shared library, but 
perhaps the API is still available in the png.h header if we can somehow 
activate it.  The question there is how good the support for the 
deprecated API is, and whether packages will break because the support 
isn't good.

>> If the old API support isn't good, I think what we should do is to have 
>> two PNG packages, png and png12, or perhaps to be more forward looking 
>> png (>=1.2.9) and png-old (<1.2.9).  Packages that want the old 
>> interface and ABI and link against png-old, which will supply just the 
>> headers and libraries.  The png package would be built with 
>> --without-libpng-compat so that it doesn't try to make those troublesome 
>> symlinks to its libraries and the Makefiles would be patched to prevent 
>> creating symlinks to the headers and *.pc files.  These two packages 
>> install completely different files so they won't conflict and can be 
>> installed simultaneously.
> 
> What do we do if "a" uses png-old and "b" uses png, and "c" uses 
> "a" and "b"?

In this case, you would lose if the two libraries actually shared 
symbols, and we would have to make pkgsrc give an error instead of 
proceeding.

> 
> What advantages do you see in splitting the package up in two?
> Not that I'm against it, I just don't see an advantage yet vs
> letting both of them in the same package, but more maintenance
> overhead.

If the old API support isn't good, then I don't see how we have another 
choice besides porting packages to using the new PNG API.  I was 
proposing a way to avoid that by keeping the old PNG headers and 
libraries around.

	Cheers,

	-- Johnny Lam <jlam@pkgsrc.org>