[arch-general] PulseAudio package group

[Eric Bélanger]

On Tue, May 18, 2010 at 11:41 PM, Jan Steffens <jan.steffens at gmail.com> wrote:
> The problem with doing that is some packages will indeed have to
> *depend* and not just optdepend on PA.
>
> PulseAudio installs some desktop files that causes it to autostart
> together with Gnome or KDE.
>
> The PA client library will start the PA server if it's not running,
> instead of failing. That means output libraries like sdl (which, by
> default, tries pulse before alsa) will start the server instead of
> failling back to other output methods.
>
> gnome-media, when compiled with PulseAudio support, will be
> inseparable from it. E.g., gnome-volume-control will only control
> PulseAudio.
>
> So as I see it, it would be hard to make PulseAudio part of ArchLinux
> without making it mandatory.

In this situation, we should go with a case by case approach. If
adding pulseaudio support to a package doesn't force the use of a
pulseaudio setup, then we build with it and add a pulseaudio
optdepends (or depends as required).  In cases like gnome-media, we
provide  a pulse and non-pulse version of the package.  Having both of
these versions in extra would enable us to use split PKGBUILD to build
them. So it will add no extra work for you.

Of course, we have to wait what the other devs have to say.  IIRC the
past pulseaudio discussions, the main  stumbling block (I don't recall
other issues) was that no dev wanted to maintain it. As you are
interested in it and with the jr dev scheme, that issue seem to be
resolved.



>
> On Wed, May 19, 2010 at 2:58 AM, Eric Bélanger <snowmaniscool at gmail.com> wrote:
>> On Tue, May 18, 2010 at 6:25 PM, Jan Steffens <jan.steffens at gmail.com> wrote:
>>> I could make PulseAudio installation significantly easier by putting
>>> specially-built packages (e.g. sdl-pulse, openal-pulse) into
>>> [community] and grouping them in a "pulse" group.
>>>
>>> This group would also include a "pulse-asoundrc" package containing a
>>> pulse-configured asound.conf, as well as depending on alsa-plugins.
>>>
>>> Should I go ahead with this? Any suggestions?
>>>
>>
>> I would suggest to apply for a jr. dev position so that the pulseaudio
>> stuff could be moved to extra.  That would save us from duplicating
>> work by having both pulse and non-pulse packages.
>>
>> BTW, does adding pulse support make it a depends or optdepends? I
>> would guess it depends on the package.
>>
>