[Fedora-packaging] Best way of patching sources for changed libbeagle?

[Ralf Corsepius]

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