Re: Box2D: providing .pc files even if upstream does not?
Hi!
On Mon, 2014-03-03 at 20:15:09 +0100, Markus Koschany wrote:
> Since I couldn't find much information about similar situations, I
> thought I'd better check with the list before I'm going to upload
> something. It seems the majority is mildly in favor, some even fiercely,
> to support pkg-config. :)
A similar situation happened with dpkg and libselinux some time ago.
dpkg used to statically link libselinux, which didn't ship a .pc file
at the time, and at some point libselinux started linking against
libsepol, so dpkg started FTBFS (#348659 and #347744). I submitted
patches against libsepol (#348947) and libselinux (#348961) to add .pc
files, and upstream only adopted them way long after they had been
shipped in the Debian packages.
At the same time I added the libsepol linking to the dpkg build system,
to catter to older libselinux/libsepol packages w/o a .pc file, and to
support non-Debian-derived systems. Current dpkg still carries that code
around (in m4/dpkg-libs.m4:DPKG_LIB_SELINUX).
But then, I still used what seemed like the most probable name to be
accepted by upstream for the .pc files, because using a Debian-specific
name would mean dpkg might need to transition to the new name and end
up supporting three code paths: no .pc file, the Debian one, and the
upstream one. So I'd recommend using a non-Debian-specific name here
too, mostly because the interfaces defined here are all hidden by
pkg-config itself (the “implementation” should not change semantics),
at most upstream might change flags or the .pc file name, which would
be no worse than having used a Debian-specific name anyway. And in this
case as Bas has mentioned, I think upstream has just misunderstood the
purpose of .pc files.
Hope that helps.
Regards,
Guillem
Reply to: