OpenAL and freealut

[Thierry Reding]

* Gerfried Fuchs wrote:
> * Thierry Reding <thierry at doppeltgemoppelt.de> [2006-02-17 10:41]:
> > just wanted to give some explanations as to the current OpenAL
> > situation.  Upstream has split freealut from OpenAL since it was last
> > packaged for Debian, which has the consequence that the new OpenAL
> > version can not be uploaded without freealut without breaking the
> > libraries and applications depending on libopenal.
> 
>  They will break anyway because the API/ABI has changed like you said
> yourself. I don't think that you need to worry about _that_ part.

Well, it still needs to be worried about. There are apps depending on
libopenal which use functionality which is not in openal anymore, but is in
freealut now. So we need to have freealut too, otherwise there will still be
breakage, even with a perfect libopenal.

> > For OpenAL I had to add an epoch in order to cope with the change in
> > the versioning scheme (dpkg considers 0.0.8 to be less than
> > 0.2005080600).
> 
>  Which is just true. :)
> 
> > There still remains a problem with libopenal still building with the
> > same soname as always, but I am not quite sure how to solve this.
> 
>  You can use the -release flag to work around non-set library version
> informations, it will put the 0.0.8 (or whatever you choose) into the
> library filename (and package name) which solves the problem, too.
> 
> > The way I understand it, upstream needs to change the library version
> > that is passed to libtool for each API/ABI change of the library,
> > which as I understand it was not the case so far.
> 
>  Exactly. This is the rationale behind the release critical bugreport I
> filed agains the package.
> 
> > This is mainly due to the fact that upstream didn't use libtool in
> > earlier versions packaged for Debian.
> 
>  And that the former maintainer of the package didn't seem to have cared
> much for the package.

We are currently working on contacting upstream about the versioning issue.
We've also prepared patches for them to apply and are going to try to
convince them that library versioning is a good thing.

> > However, the library version is still the same as ever (0.0.0) thus
> > still breaking packages built against earlier versions of libopenal.
> 
>  Right. Use -release if possible instead -version-info, by no means you
> should start -version-info because this is a no-go for distributors.

One problem I see with using -release is that it's going to change the soname
as well, thus we'll be required to change the package name too. The problem I
have with this is that once version-info things are worked out upstream, how
do we change back to our old versioning scheme. Do we then omit -release
again? Maybe it would be better to wait for a next upstream release so that
we may get the problem solved once and for all?

Another possibility might be to ask upstream to start with a sover of 1, so
that the old library (the CVS snapshot) could go by the soname
libopenal.so.0, and libraries from version 0.0.8 and up by the soname
libopenal.so.1?

Any thoughts, comments or recommendations?

Thierry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20060217/04c637e0/attachment.pgp