Bug 62865 - PulseAudio 3.0 requires Alsa >=1.0.24.1 but checks for >=1.0.19
Summary: PulseAudio 3.0 requires Alsa >=1.0.24.1 but checks for >=1.0.19
Status: RESOLVED FIXED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: build-system (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-28 13:10 UTC by Peter Åstrand
Modified: 2013-07-10 14:32 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Åstrand 2013-03-28 13:10:30 UTC
PulseAudio 3.0 requires Alsa >=1.0.24.1. However, configure.ac only checks for >=1.0.19. If you have an older version, the build fails:

In file included from modules/alsa/alsa-mixer.h:51:0,
                 from modules/alsa/alsa-util.h:36,
                 from modules/alsa/alsa-util.c:46:
modules/alsa/alsa-ucm.h:27:22: fatal error: use-case.h: No such file or directory
compilation terminated.

IMHO, support for the use case manager should be optional.
Comment 1 Tanu Kaskinen 2013-03-29 11:55:48 UTC
The version check is already fixed.

I don't personally see the point of complicating things by making UCM an optional feature.
Comment 2 Peter Åstrand 2013-03-29 12:24:52 UTC
(In reply to comment #1)
> The version check is already fixed.

Yes, apparently on master, but not on stable-3.x. 


> I don't personally see the point of complicating things by making UCM an
> optional feature.

The point would be to be able to use modern versions of PulseAudio on systems which does not have bleeding edge versions of Alsa: Debian (even unstable) has 1.0.23. The latest CentOS/RHEL has 1.0.22. Suse Linux Enterprise has 1.0.18. We (=Cendio) are also shipping PulseAudio in our ThinLinc client, which targets many thin terminals, which certainly does not have the latest Alsa. 

If you require bleeding edge versions of Alsa (and other software packages), this means that you are limiting the audience and potential use of PulseAudio. This in turn, means that we and others are forced to use older versions, and cannot contribute to the development. We have done major contributions in the past, including the Win32 and Solaris ports, the alsa-pulseaudio bridge etc. We would be glad if we could continue contributing in the future. 

Thus, from our perspective, it is critical that we can use slightly older versions of Alsa. I did some work yesterday and it wasn't that difficult to introduce an ifdef HAVE_ALSA_UCM. Are you sure you are not interested in such a patch?
Comment 3 Tanu Kaskinen 2013-03-29 14:10:30 UTC
Users of released (and thus more or less frozen) distribution versions aren't our target audience. If they were, we couldn't depend on any software that was newer than five years or so. (How long are RHEL releases, for example, supported by Red Hat?) Users are expected to get new PulseAudio versions when they upgrade their operating systems.

I can see how this is a problem for you, if you want to distribute PulseAudio directly (skipping the distribution middle-man) to your users, but you aren't prepared to distribute also all of PulseAudio's dependencies in a similar manner. I don't like this situation either - I'd like to target users directly, but that's just too much of a hassle. I wish Zero Install (http://0install.net/) or something like it would really take off.

Anyway, if you write a patch for relaxing the alsa-lib version requirement, I don't think there's much reason for me to reject it. Just don't expect me to write that patch.

I'm using Debian testing myself, BTW, and it has libasound2 1.0.25-4, so your information about Debian unstable's alsa-lib version is outdated.
Comment 4 David Henningsson 2013-04-04 10:03:57 UTC
(In reply to comment #3)
> Users of released (and thus more or less frozen) distribution versions
> aren't our target audience. 

I tend to disagree; it is still helpful for users of stable distros to help out with testing new versions. Having a little bit better backwards compatibility generally helps.

This is a trade-off though, and we could use a generic discussion about how long we should keep it though. My gut feeling is that it would be okay to move forward to mandatory depend on something that has a stable release about one to two years ago or so, but to determine this on a case-by-case basis.
Comment 5 Arun Raghavan 2013-04-18 04:24:15 UTC
(In reply to comment #4)
[...]
> This is a trade-off though, and we could use a generic discussion about how
> long we should keep it though. My gut feeling is that it would be okay to
> move forward to mandatory depend on something that has a stable release
> about one to two years ago or so, but to determine this on a case-by-case
> basis.

For what it's worth, I agree with this.
Comment 6 Arun Raghavan 2013-04-18 04:37:07 UTC
Closing this for now. As Tanu notes, patches to make UCM optional are welcome (with a personal caveat from me that they should not be too intrusive).

I don't think supporting ALSA versions more than 2 years old is a useful way to spend our time.
Comment 7 Pierre Ossman 2013-07-10 14:32:53 UTC
Opened bug 66777 for a suggested patch.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.