On Thu, 04 Apr 2013 08:26:07 -0400, Stephen Gallagher wrote:
> It would have been possible for you to work around the missing
> #include by adding it to the source code you wanted to build. Never
> has there been a requirement to "wait for alsa-lib".
Sure, but my interpretation of the problem is that this was causing
FTBFS on any package in F19 that was trying to BuildRequires:
alsa-lib-devel because of changes made in GCC. It seems like the
correct behavior for alsa-lib to restore the existing functionality
than to force all downstreams to include a hack around the problem.
And it was nice and easy.
Of course! Just to be clear, I didn't object to fixing alsa-lib.
I'm not convinced *all* alsa-lib-devel API users are affected by that
problem, however. For example, Audacious Plugins' ALSA driver includes
<alsa/asoundlib.h> from alsa-lib-devel and has not failed during rebuilds
in Rawhide or elsewhere - it includes a couple of other C StdLib headers
(such as stdint.h). The ticket in bugzilla has been opened end of 2012
already, and no other packager has joined there.
But yes, I certainly follow your point about his particular package
having the *option* of hacking around it if there was an urgent need.
That's what I meant. :)
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc5.git1.301.fc19.x86_64
loadavg: 0.19 0.71 0.43