Upgrading libpng: shall we move to 1.4.x or 1.5.x?

[Michael Schwendt]

On Wed, 09 Nov 2011 10:42:10 -0500, TL (Tom) wrote:

> > On Fri, 2011-11-04 at 13:12 -0400, Tom Lane wrote:
> >> I plan to provide the 1.2.x libpng shared library (and only the library,
> >> not its devel support files) in a libpng-compat subpackage for the time
> >> being.
> 
> > Any reason why the compat package ships the libpng-1.2.pc pkg-config
> > file?
> 
> Yeah: I tried it without first, and found that I couldn't rebuild
> anything.  There are boatloads of packages that have pkgconfig(libpng12)
> as an RPM-visible dependency, so if the compat package doesn't supply
> it, those packages won't install and you can't rebuild any of their
> dependencies.  I have no idea why it was considered a good thing for RPM
> to track this type of dependency, but it does.

It is fragile, unfortunately, but not bad. 

Automatic Provides/Requires for pkg-config interpackage dependencies are
helpful. Packagers have had problems getting the -devel dep-chains as
complete as necessary to not break the .pc file inter-dependencies.

However, one could say that you've injected a broken package into the
build-system by including a .pc file it in without including the
corresponding headers and library. A compat package is not supposed to
be a -devel package either (unless it is a special case of a compat -devel
package).

The fundamental problem with the automatic pkg-config provides is the
extra version in the .pc file name. Those extra versions are poor design,
a poor choice by the developers of the library's .pc file, because
pkg-config has means to query the internal version in the .pc file
instead.

With

  pkgconfig(libpng) = 1.2.46
  pkgconfig(libpng12) = 1.2.46

once libpng12.pc gets removed from the distribution, the dep-chains
break, of course.

As a temporary work-around, you could have provided that thing manually
in the libpng-devel upgrade instead of including the actual libpng12.pc
file:

  Provides: pkgconfig(libpng12) = %{version}-%{release}

Any configure script or .pc file using a hardcoded "libpng12" name
would fail to build, but that would be better IMO than offering an
incomplete broken compat package that confuses the buildroots.