Fwd: OpenAL Regressions In Intrepid
nullack at gmail.com
Fri Sep 26 05:55:13 UTC 2008
Gday QA folks :)
A number of commercial clients I consult too have complained about how Linux:
1. Requires too much of a continual investment to keep working on all
2. Is too hard to support against all possible builds.
Recently I had a similar event happen when I tried to install a closed
source linux app. The app didnt work because there was an ABI bump in
revisions and the required external library could no longer be found.
I reluctantly invalidated the bug report and this served to reinforce
in my mind how things get broken in Linux and the upkeep thats
I realise this is an architectural issue that isnt limited to Ubuntu
but figured it was worth a brief moment to jot down my thoughts (and
an excuse to take a break from my current work haha!). Some somewhat
* Why cant we retain legacy support in ABI bumps?
* Why are products being hard coded to specific version numbers for
external library dependencies?
* Why isnt the architecure of Linux module, nice and future proof to
improvements in libraries as time moves on?
I understand this isnt a topic about fixing something and getting
immediate results in say Intrepids release, but I am convinced FOSS
needs to do a better job to make it easier for commercial apps. If you
take a look at the history of flash support on Linux, much of the
grief there is due to changes in Linux ABIs and packages, rather than
actual problems with flash specifically. The world is not limited to
software than is open and easily changed via a recompile.
---------- Forwarded message ----------
From: Christopher Halse Rogers <chalserogers at gmail.com>
Subject: Re: OpenAL Regressions In Intrepid
To: Null Ack <nullack at gmail.com>
On 9/24/08, Null Ack <nullack at gmail.com> wrote:
> Gday everyone,
> The Linux Standard Base is surely a good thing. I don't know if OpenAL
> is included in the LSB or not. What I do know is that someone decided
> to change naming for OpenAL in Intrepid and this is causing many
> regressions in other apps that now can't find OpenAL.
> Can I please refer people to this bug:
> Some questions that come to mind are:
> 1. Why did we change the naming?
This one's easy to answer: Because the library's ABI changed. This is
also why the proposed solution of creating a symlink from
libopenal.so.1 to libopenal.so.0 won't work.
> 2. What is the best solution in the long term here for us?
Exactly what's happening now. I note that libopenal0a is still
installable - at least, I've got both libopenal0a and libopenal1
installed, although it seems that the libopenal0a binary package has
been removed from the archives in an Not-Built-from-Source sweep.
It's possible that the Replaces: field doesn't do what you think it
does (all it does is allow a package to overwrite a file provided by
the Replaces'd package).
Unless we want to keep the old source package around, producing an old
OpenAL library, like we do for libstdc++5. I think this would only be
considered in exceptional circumstances, however - (almost) all the
software in the repositories is now built against the newer library.
Those packages still built against libopenal0a should have bugs filed
against them - I'll get around to this later today if no one beats me
More information about the Ubuntu-qa