Bug 225044

Summary: guichan 0.6.1 update is available
Product: [Fedora] Fedora Reporter: Wart <wart>
Component: guichanAssignee: Wart <wart>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: hdegoede
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-04-14 05:22:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 232873    
Bug Blocks: 225015, 229120    

Description Wart 2007-01-27 22:00:24 UTC
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.

Comment 1 Johan Kok 2007-02-04 18:49:24 UTC
See also bug #222184 and the thread on the fedora-extras mailinglist about the packager being AWOL.

Comment 2 Wart 2007-02-04 21:57:36 UTC
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.

Comment 3 Wart 2007-02-27 01:10:22 UTC
Reassigning this bug to myself since I am now the new owner of this package.

Comment 4 Hans de Goede 2007-03-18 18:19:41 UTC
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.


Comment 5 Hans de Goede 2007-03-18 18:25:30 UTC
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.


Comment 6 Wart 2007-03-19 06:16:59 UTC
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.

Comment 7 Wart 2007-04-14 05:22:19 UTC
Updated in FC6 and rawhide