Subject: Re: Warning: graphics/png is currently broken
To: NetBSD Packages Technical Discussion List <email@example.com>
From: Johnny C. Lam <firstname.lastname@example.org>
Date: 04/17/2006 11:46:23
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
>> 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
> 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
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
-- Johnny Lam <email@example.com>