>Number:         12856
>Category:       pkg
>Synopsis:       libpng revisions > 1.06 REMOVE functions without a shlib major version bump.  This causes extreme lossage if the libpng package is upgraded.
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun May 06 22:39:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        20010504
>Organization:
	The NetBSD Project
>Environment:
System: NetBSD becasse.cs.stevens-tech.edu 1.5.1_ALPHA NetBSD 1.5.1_ALPHA (BOCK) #16: Wed Feb 28 16:55:59 EST 2001 root@amstel.cs.stevens-tech.edu:/usr/src/sys/arch/i386/compile/BOCK i386


>Description:
libpng in pkgsrc was at 1.06 for quite some time.  Now, however, many
many packages in pkgsrc require a newer libpng.  Unfortunately, the
libpng package upgrade wasn't really done right, with copious help
from the (not-overly-bright, evidently!) maintainers of libpng; newer
libpng versions have had functions REMOVED without bumping the shlib
major number, and now spit out ugly warning messages at initialization
and then cause executables linked to older libpng versions to dump core.

The right solution to this is to bump the libpng major number in a patch,
even if the libpng maintainers are too stubborn to do so.  There is *NO*
reason why the major number of the NetBSD shlib must be the same as the
major part of the version number of the software itself.  This will cause
programs linked to old libpng to still run correctly if the library
itself is present, and will allow libpng to be upgraded in-place without
requiring a rebuild of almost every graphical application in pkgsrc.

To get this to all build and install right, it may be necessary to rename
the libpng package so that both an old version of libpng (for old apps
linked to libpng.so.1) and a new version (for new apps, linked to
libpng.so.>1) can be installed at once without resorting to pkg_delete -O
or other hackery.  In any event, the current "solution" is Just Plain
Broken; it's absurd to expect that users will spend *weeks* (on slower
platforms) rebuilding every package caught by the dependency fan-out from
libpng just to be able to build *one* new package that requires libpng >
1.0.6; it is also absurd to remove functions from a shared library, *ever*,
without bumping the library major number; this kind of bad engineering
would not be tolerated elsewhere in NetBSD, and though obviously it's the
libpng maintainers' fault, not the pkgsrc developers' fault, now that it
has become obvious we ought to fix it.

>How-To-Repeat:

Try to build or install any package requiring libpng > 1.0.6 on a system
with libpng 1.0.6 installed; scream in agony when you discover that you
will have to rebuild almost all of pkgsrc just to stop losing.

>Fix:

Bump the libpng shared library major number, as is always necessary when
functions are removed from any shared library.

>Release-Note:
>Audit-Trail:
>Unformatted: