Bug 225044

See also bug #222184 and the thread on the fedora-extras mailinglist about the packager being AWOL.

Thanks for the tip.  I'm aware that this maintainer's packages may get orphaned.
 If that happens then I'll step up and take over this package myself.

Reassigning this bug to myself since I am now the new owner of this package.

Replying to your mail on the fedora-games-list:

> I'm not concerned about the update itself, but with the proper way to 
> create a compat-guichan05 package (needed by sear).  I've haven't seen 
> any 'best practices' for creating compat packages, so I'm not quite sure 
> of the best way to start on this one.
> 
> Presumably I'll have to rename the header directory and rename the 
> libraries to make sure they don't conflict with the non-compat package, 
> as well as modify sear to use the new compat header/library names.

Well if guichan-0.6 isn't ABI compatible with guichan-0.5 then the lib should
have a different soname, so you do not need to rename the lib. Basicly you can
use the old guichan-0.5 spec except that the headers should go to
/usr/include/guichan-0.5 and the .so symlink from the devel package (which
should be the only identical named file under /usr/lib) should go to
/usr/%lib/guichan-0.5, and the symlink must be adjusted ofcourse to not point to
lala-la land.

Then sear should be compiled with -I/usr/include/guichan-0.5 added to the (front
of) CGLAGS and -L/usr/%lib/guichan-0.5 to (the front of) LDFLAGS. Thats really
all there is to it.

AAIee, I just took a look at rpm -ql guichan (after installing 0.5) and the
soname is /usr/lib64/libguichan.so.0, full lib name
/usr/lib64/libguichan.so.0.0.0. This is a typical sign of upstream using libtool
and not setting any release fields, so most likely the soname for 0.6 (I'll take
a look) will be .0 too, which is bad.

Time to go and educate upstream. For now a good workaround for this is to add 
-release %{version} to the LDFLAGS passed to libtool, this will make libtool
generate:
/usr/%lib/libguichan-%{version}.so

This means that any new upstream release will use a new soname (and thus all
using apps / libs need to be recompiled. This is for the best, as clearly
upstream is not aware / doesn't care about ABI compatibility, and especially
since this is c++ unless upstream is very carefull, the ABI will change. Unlike
with C, with C++ the abi can change by merely adding additional methods to classes.

For the record I just build guichan-0.6.1 and indeed they didn't change the
soname. So as suggested please add -release %{version} to LDFLAGS.

If this is all abracadaba to you let me know and I'll try to explain better.

p.s.

You could take a look at ogre-1.2.2-soname.patch, from the ogre package which
does the -release %{version} adding. As ogre has the same problem.

Talking about ogre, do you happened to be interested in taking it over, its a
bit of a PITA and I've close to zero use for it.

Thanks for the advice.  It makes perfect sense.  I've submitted a
compat-guichan05 package for review (bug #232873) and have a local copy of sear
that compiles with this compat package.

Unfortunately, I think I'd be over my head with ogre, and would likely not be
very effective at handling its issues.

Updated in FC6 and rawhide