Bugzilla Bug 35412

Alsa-lib 1.0 library's api is binary compatible w/ the older versions- the
compilation however has a 
new api that is the default defined when included, unless you define 2 symbols
prior to include 
alsa/asoundlib.h to use the old api.

Using the old api doesn't break anything, so that's not an issue.  The default
being the new api 
however breaks all apps that use the old api w/out those definitions...

Reproducible: Always
Steps to Reproduce:
1. emerge >=media-libs/alsa-libs-1.0
2. emerge kde-base/arts
Actual Results:  
Compilation failed due to the new api.

Expected Results:  
Source should define the necessary definitions to get the old api, and compile
successfully...

This basically breaks all previous apps compilation against alsa-lib.  Kind of
bad.
Easy to fix though.

Created an attachment (id=21911) [details]
alsa-lib-fix eclass that contains a general find/sed fix

This class is two functions- 
alsa-lib_fix_includes()- this can be passed multiple directories- performs a
recursive find for sourcefiles/headers that have <alsa/asoundlib.h> to patch,
using sed to fix the includes.

alsa-lib_src_unpack() - exported function, calls base_src_unpack and calls
alsa-lib_fix_includes

Created an attachment (id=21912) [details]
quick scan through ${PORTDIR} for packages/versions that likely are nailed by
this.

Not guranteed to be accurate- some of the newer sources may already be doing
the define.

imo we should patch rather than make an eclass

I agree, patches are better, and I fully expect this to be obsoleted by newer
versions of the packages that are afflicted at some point.

The thing is, users are already running into this breakage.  And that's a
crapload of patches to create on short notice (granted they are one liners, but
multiple-versions)

I went the eclass route since it's the quickest way to fix the problem till
either we have all the patches needed for each version we wish to fix, or
upstream maintainers release a new version w/ the fix (thus forcing all users
to that possibly untested version).

qa'ish issue, so cc'ing spider on this one as well.

*** Bug 35522 has been marked as a duplicate of this bug. ***

This lib should not be unmasked until xawdecode-1.8.2 is unmasked- 1.8.2
includes a configure fix for the >=alsa-lib-0.9.x
This fix can probably be back ported, or just wait until it's unmasked.

Hokay... I've gone through all ebuilds that have media-libs/alsa-lib as a
dependency, as of 10/23/04.  Patches have been submitted, so the bulk of this
issue should *hopefully* be handled.
I'd expect a few to pop up here and there since I was checking stable packages
only, but hopefully most of it is handled.

Side note, the fix should be like this-

#include <alsa/version.h>
#if SND_LIB_MAJOR==1 
# define ALSA_PCM_OLD_HW_PARAMS_API
#endif
#include <alsa/asoundlib.h>

Note the lack of ALSA_PCM_NEW_HW_PARAMS_API; torbenh caught that (thanks again).

Brian, how many of these packages have the fix in stable?  I'd like to push for
getting alsa-1 stable sometime around mid March to mid April.

When I originally went through and patched all of this, if the package was
stable at all for x86, I patched the max stable version.  Otherwise, I patched
the max unstable version.

To be honest, I'm not really how much of it is in stable or not, since I was
patching quite a few packages.  I can go hunting through and check up on it
though.

i know you're busy, but if you could try to get these fixes into stable over
the next month or so, that'd be great...

Ohk- since I don't feel like being bitten by the 'we unmasked a new version,
and it died against alsa-lib' I'm going to extend the patches through each
version.  For the most part, we can use the same patch (thank you patch
fuzznyess).
I'll start on it next week, appending which packages have been completely
checked out to this bug.