On Mon, 2010-11-15 at 06:35 +0800, Ray Rashif wrote:

On 15 November 2010 04:11, Jan Steffens wrote:

...

One of the problems of PulseAudio is that it pretty much becomes the default as soon as you install it: - The client library will start the server if it's not running. - pulseaudio will install .desktop files that autostart the server together with Gnome or KDE.

Splitting libpulse would prevent that, but I believe we still need to test on a per-application basis whether we can enable PulseAudio support (with a dependency on libpulse) without breaking fallback to ALSA on systems without pulseaudio.

Some packages (like sdl and openal) look for libpulse dynamically and will still work even though the lib is missing, so they only need an optional dependency.

A tentative repo to test this out wouldn't be a bad idea, IMO.

AFAIK that repo was called "community". As for splitting up packages for pulse support: whenever depending on libpulse still keeps pulseaudio support optional, I'd rather depend on libpulse than split the package itself.

On Mon, Nov 15, 2010 at 8:02 PM, Stéphane Gaudreault wrote:

Out of curiosity, what would the consequences to have all these news packages in [community] instead of [extra]?

PulseAudio is already available in [community], minus the libpulse split. Moving it to [extra] would allow us to have (optional) dependencies on it.

Le jeudi 25 novembre 2010 16:15:33, Jan Steffens a écrit :

On Sun, Nov 14, 2010 at 9:11 PM, Jan Steffens wrote:

...

I would like to propose moving support for the PulseAudio sound server into Arch Linux proper. This would also be in preparation for the eventual arrival of Gnome 3, since it will be unlikely we can effectively maintain the needed GStreamer patch any more.

To that effect I have created a plan:

---

To provide PulseAudio in [extra]...

Move the following packages from [community] to [extra]: - libasyncns - rtkit - pulseaudio (split into pulseaudio and libpulse) - alsa-plugins - pulseaudio-alsa Configuration package, contains /etc/asound.conf depends on pulseaudio, alsa-plugins - pavucontrol - paprefs - pulseaudio-mixer-applet - ossp provides osspd OSS emulator

Rebuild the following packages with PulseAudio support: - sdl (sdl-pulse in AUR) - openal (openal-pulse in AUR) - libgstreamer0.10-good split gstreamer0.10-pulse (in community) - libao split libao-pulse (in community) - libcanberra split libcanberra-pulse (in community) will be a split plugin instead of a wholly rebuilt copy - gnome-media split gnome-media-pulse (in community; rebuilt with --enable-pulse) - gnome-settings-daemon split gnome-settings-daemon-pulse (in community; rebuilt without gstreamer patch)

Provide the following groups: - pulseaudio-gnome pulseaudio-alsa libcanberra-pulse gstreamer0.10-pulse gnome-media-pulse gnome-settings-daemon-pulse

---

One of the problems of PulseAudio is that it pretty much becomes the default as soon as you install it: - The client library will start the server if it's not running. - pulseaudio will install .desktop files that autostart the server together with Gnome or KDE.

Splitting libpulse would prevent that, but I believe we still need to test on a per-application basis whether we can enable PulseAudio support (with a dependency on libpulse) without breaking fallback to ALSA on systems without pulseaudio.

Some packages (like sdl and openal) look for libpulse dynamically and will still work even though the lib is missing, so they only need an optional dependency.

I would be maintaining split -pulse packages where needed.

If there are no objections, I would move it from [testing] tomorrow.

At first I was worried about KDE, so I tested the new KDE packages in [testing]. A new dependency of phonon install libpulse (the full pulseaudio package is optional). After a little research and some testing I found that this libpulse dependency cannot be optional if we want to enable support for PA in phonon. Since other distributions (at least Debian/Kubuntu and Fedora) are doing something very similar and that the use of PA in phonon is optional (alsa still works as expected), I would say +1 Stéphane