Subject: Re: Warning: graphics/png is currently broken
To: Johnny Lam <firstname.lastname@example.org>
From: Thomas Klausner <wiz@NetBSD.org>
Date: 04/17/2006 17:25:07
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