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?

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

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.
 Thomas