Bug 225044 - guichan 0.6.1 update is available
guichan 0.6.1 update is available
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: guichan (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Wart
Fedora Extras Quality Assurance
:
Depends On: 232873
Blocks: 225015 229120
  Show dependency treegraph
 
Reported: 2007-01-27 17:00 EST by Wart
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-14 01:22:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Wart 2007-01-27 17:00:24 EST
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 13:49:24 EST
See also bug #222184 and the thread on the fedora-extras mailinglist about the packager being AWOL.
Comment 2 Wart 2007-02-04 16:57:36 EST
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-26 20:10:22 EST
Reassigning this bug to myself since I am now the new owner of this package.
Comment 4 Hans de Goede 2007-03-18 14:19:41 EDT
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 14:25:30 EDT
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 02:16:59 EDT
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 01:22:19 EDT
Updated in FC6 and rawhide

Note You need to log in before you can comment on or make changes to this bug.