On Mon, 2007-12-10 at 11:35 -0500, Tom "spot" Callaway wrote:
On Mon, 2007-12-10 at 13:56 +0100, Sebastian Vahl wrote:
I need some help with the new libbeagle-0.3.0. This one is listed in pkg-config with "libbeagle-1.0". The configure script of kerry (and also brasero and yelp) are explicit checking for "libbeagle-0.0". Upstream hasn't catched up the new beagle, yet, so I have to figure out what is the best way of preparing my package (kerry) for the new libbeagle version. And here I need some help because I'm not very familiar with configure scripts. :)
My attempt here is to avoid a patch and change the libbeagle version with sed:
Seems fine. This is one of my pet-peeves with pkgconfig, by embedding a "ABI/API/Arbitrary random version" in the identifier name, it makes looking for the related values much much more difficult.
Instead of just asking pkgconfig for libgtkhtml's libs/headers, I've got to check for libgtkhtml-3.14, then libgtkhtml-3.12, libgtkhtml-3.10, libgtkhtml-3.08, libgtkhtml-3.06, libgtkhtml-3.04, and so on, ad infinitum.
What you say only applies if a library's API is backward compatible to its predecessor.
To be fair, this isn't pkgconfig's fault, it's GNOME's fault, as it seems to be the one doing this.
Right, if a library's upstream is "backward compatible" they shouldn't bump the *.pc's file name, but only the internal version number.
Evolution recently dropped this practice, one can only hope that the rest of GNOME follows.
This advice is short-sighted.
Versioned *.pc are one way (another one is using a different PKG_CONFIG_PATH) to permit parallel installation of API incompatible packages. So my advice would be library upstreams not to tie their *.pc's file names to package versions, but to API-versions, instead.
Ralf