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 -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
