A new version of the guichan library has been release: 0.6.1. This update is required by the latest manaworld release. Another package currently under review (bug #198839) still requires the current guichan-0.5.0. It would be nice if you could make a compat-guichan05 at the same time as the update to 0.6.1 so that both packages (sear and manaworld) could coexist with different guichan versions.
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