In article <4443B84F.1090603@pkgsrc.org>,
	"Johnny C. Lam" <jlam@pkgsrc.org> writes:
> 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.

The point of PNG_INTERNAL is to preserve *binary* compatibility
in the latest library, while requiring any re-compilied packages
to update source to the new API (by deliberately breaking source
compatibility).  No user of the library is supposed to define
PNG_INTERNAL.  If they don't want to update source to the new API,
it would be be better to require an older version of the library.

I gather, with png-2.0, they're going to clear out the crust from
the primary installed library. The "compat" option is evidently to
preserve that feature -- binary compatibility -- for customers who
feel they need that.

All pkgsrc packages have been fixed to build against png 1.2.* for
a long time now, so finally removing the pre-1.0 ABI should have
no consequences, and we don't need the compat option. (In theory,
there is a consequence:  I can presently install a NetBSD-1.3
binary package that depends on png-0.95, but let that dependency be
satisfied by a new build of png-1.2.8. We'll lose that, but I think
no one does that anyway: it would only be a useful practice if all
libraries handled compatibility issues with the same diligence as
png, which they don't.)


Frederick