OpenAL and freealut

[Reinhard Tartler]

On Fri, Feb 17, 2006 at 03:14:47PM +0100, Thierry Reding wrote:
> * 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.

Those applications will have to be adapted for the newer openal anyway.
I'n order to do the transition as smooth as possible, let's prepare new
openal and freealut packages for experimental, and adapt all reverse
dependencies for them.
 
> > > 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?

Wait and see is always a solution, but not the most satisfying one. If
we use the -release now, we end up with an soname of libopenal-0.0.8.so.
Later, when upstream introduces proper library versioning, we drop
-release, and get a new soname of libopenal.so.2 or whatever. 

I don't see any drawbacks in using the -release right now.

> 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?

We should ask them to start with soname of libopenal.so.1 in any case,
because openal in its current form is not compatible with what we
currently have in debian anyway. If there are other libopenal.so.1
binaries around in other distributions, they should start with something
even higher.

Gruesse,
	Reinhard