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.
--
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel
