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