libsdl-1.2 package has unnecessary variants

Bug #128447 reported by Ryan C. Gordon
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libsdl1.2 (Ubuntu)
Fix Released
Wishlist
Unassigned

Bug Description

Doing an "apt-cache search libsdl" shows these packages:

  libsdl1.2debian
  libsdl1.2debian-all
  libsdl1.2debian-alsa
  libsdl1.2debian-esd
  libsdl1.2debian-oss
  libsdl1.2debian-arts
  libsdl1.2debian-nas

...all of which are the same library, providing the same API to applications, except each is built with different audio backends (ALSA, Esound, /dev/dsp, etc).

We've spent a lot of time in the last few versions of SDL cleaning it up so that it can use these various backends without explicitly linking to them. The latest SDL release, 1.2.12, can be built as a binary that supplies any GNU/Linux audio or video target without explicitly linking to anything by glibc.

Things like xlib, alsalib, etc, will be dlopen()'d at runtime, and if they aren't available, SDL will try other avenues until it finds the optimal available path.

The end result is that you no longer need a separate SDL package for each target, as one build will fit all scenarios, and SDL will also be more robust against uncommon scenarios, like a user attempting to run software on the framebuffer device when there's no X server. This also allows SDL to gracefully handle things that may not be available at the moment on a given system, and it also allows a more flexible library without having ever-increasing complexity in the package system (for example, 1.2.12 added PulseAudio support, but it wouldn't necessarily need yet-another libsdl1.2 package).

SDL builds like this by default in 1.2.12, if you build it with gcc 4.x, and the configure script sees the dev packages for various backend targets (so it will compile against, say, the alsalib headers, but it won't link against the alsalib libraries until it tries to dlopen() them at runtime, doing the right thing if they aren't found then).

Is it possible to get these all merged into one, unified package that is built with all the audio/video backends?

Thanks,
--ryan.

Revision history for this message
Jonathan Rogers (jonner) wrote :

I'm not positive, but it looks like libsdl1.2debian-all already is the unified package you describe. I only found this page because I'm running Hardy and trying to get everything to work well with PulseAudio, including SDL apps. The libsdl1.2debian-pulseaudio package was already installed on, but all SDL apps would die with "Couldn't open audio device!". After chasing various potential causes of this problem, including timidity configuration which playsound misleadingly blames, I finally discovered that when I install libsdl1.2debian-all and set SDL_AUDIODRIVER=pulse in the environment, SDL apps work fine with PulseAudio, though they don't when libsdl1.2debian-pulseaudio is installed.

So, I agree wholeheartedly with your proposal. It looks like the specialized packages are not only unnecessary, but harmful. Probably, simply eliminating them and setting SDL_AUDIODRIVER to the desired driver in the global environment somewhere would be far better.

Revision history for this message
Brice Terzaghi (terzag) wrote :

libsdl-all is indeed the unified package that include every sound engine.

Problem is
1) every independant engine excludes the others (i.e. installing libsdl-pulseaudio removes libsdl-alsa for example)
2) some apps are built with a specific engine (to be honest, I only saw this once with a package for Second Life that was dependant of libsdl-alsa; although it's unusual, it can happen)

Would it be possible to make every engine (every package) installable simultaneously and changing libsdl-all as a metapackage that would just install all the specific ones ?

Daniel T Chen (crimsun)
Changed in libsdl1.2:
importance: Undecided → Wishlist
Revision history for this message
Felix Geyer (debfx) wrote :

Fixed in 1.2.14-6.4ubuntu1.

Changed in libsdl1.2 (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.