Subject: Re: Warning: graphics/png is currently broken
To: None <email@example.com>
From: Frederick Bruckman <firstname.lastname@example.org>
Date: 04/17/2006 20:14:35
In article <4443B84F.email@example.com>,
"Johnny C. Lam" <firstname.lastname@example.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.)