RFC: Possible Transition from openal-0.0.8 to openal-1.1.0~svn*

["Andres Mejia" <mcitadel@gmail.com>]

Hello,

I was wondering if anyone here was interested in working to get openal
packages updated to the latest version in SVN (pre 1.1.0). I've
already done some work in a personal branch I created for openal to
make it easier to transition to the new libraries (I didn't want to
stomp all over Cyril's changes). The branch is
svn://svn.debian.org/svn/pkg-games/packages/branches/openal/andres .

Here's what I've done.

The libopenal1 package doesn't provide a Conflicts, Provides, or
Replaces field. This I think is unnecessary and allows for packages
still using the old libraries to continue to work. The libopenal1
package will use /etc/openalrc1 to avoid a name conflict with the old
libraries.

I renamed libopenal-dev to libopenal1-dev. This is so anyone wishing
to use (or test) their packages using the new libraries can
Build-Depends specifically on the openal-1.1.0 development files and
thus the new libraries. I do have a Conflicts of libopenal0a-dev for
libopenal1-dev. I think the old packages should name the development
package libopenal0a-dev and provide a dummy package libopenal-dev that
Depends on the real development package. This way, if openal-1.1.0
becomes stable enough, the dummy package could be changed to Depend on
libopenal1-dev.

I changed back to using autotools. This was only because I was more
familiar with autotools and I wanted to provide some DEB_BUILD_OPTIONS
in debian/rules.

I've also updated the TODO file.

 * yasm support.
   yasm seems to be supported as the default assembler upstream. Also, it seems
   that yasm has more features. We should probably attempt to have openal build
   with yasm as the default assembler. Also, we should use the latest version
   of yasm (http://bugs.debian.org/440528).
 * Transition.
   We should support a transition from the old libopenal packages to the new
   ones. The old development packages should be reuploaded using the name
   libopenal0a-dev and have a Conflicts of libopenal1-dev. There should also be
   dummy package named libopenal-dev which should have a Depends on the more
   stable development packages (currently libopenal0a-dev). The libraries
   shouldn't contain any Provides, Replaces, or Conflicts fields.

 -- Andres Mejia  Fri, 18 Jan 2008 13:37:14 -0500

Just as a reminder, here's what Cyril had in the TODO file. I've
already posted a comment about the libtool files.

 * Check the B-D:
   - Check the architecture(s) for which `nasm' is needed. There are some
     conditions on whether the platform is x86 or x86_64, in CMakeLists.txt.
 * Adjust the -dev package:
   - Probably do not attempt to ship evil .la files, currently commented out in
     the install file. Document it in the changelog once it is decided.
     + This I'm sure is a bad idea as we can not be sure that no project will
       ever need these files. I've uncommented the install file for these files.
       -- Andres Mejia

 -- Cyril Brulebois


-- 
Regards,
Andres Mejia