Le vendredi 16 janvier 2009 à 17:35 +0100, Lennart Poettering a écrit : > Hmm. Somehow I get the feeling that the only distribution where this > really matters is Debian Not quite; AFAIK Gentoo and OpenSolaris have not embraced PulseAudio as well. > -- because you guys want to ship all and > everything and leave the user the decision what he uses and what he > doesn't. It’s not as if we wanted to leave such choices; this should be automated, everywhere possible. Currently, the sound setup for which we provide full support is ALSA. However some hardware requires OSS, as well as the freebsd port, so we also support OSS everywhere possible (which is actually quite easy). However, switching to supporting only PA would mean a large number of users wouldn’t have any sound at all. > (I mean, you guys even include OSS4!) I wonder where you got that idea. We still ship OSS3 modules for hardware that doesn’t have decent ALSA support, but not OSS4. > The other distributions > do an informed decision whether they want to adopt PA or not and then > integrate it fully or not. Currently, this is not a big problem, since in those choosing to ship PA by default, users can disable it and have working sound under GNOME. With the changes that are being made currently (like, only supporting PA in g-s-d and g-media), this is a lose-lose choice. Either we choose to lose some users, either we choose to lose functionality. > Now, that Debian works that way is something I accept, and not even > criticise. However what I don't see here is why this should hold > upstream back and requires us to hack kludges for you that only you > need. Actually it is us who will have to hack kludges to have something that works; just like we had to do for the session in 2.24. I think however that it would be possible to develop in a way that can benefit everyone better. I find it hard to believe that all users who complained of the broken sound in Ubuntu and Fedora will be happy to see that removing PA is not enough anymore when they upgrade to GNOME 2.26. > I also don't follow why this compile time decision really is that bad > for you at all. I mean, you guys ship a lot of packages in multiple > versions with different compile settings. That starts with the kernel, > but continues with VIM, with emacs and gazillions of other > packages. You guys even invented the alternatives system just for > this! I’m starting to wonder whether you actually read the emails in this thread, or just rush like every time someone dares to claim that PulseAudio is not perfect. Again, I don’t have a big problem with building the software twice; we will be perfectly able to hack a wrapper, thanks. I have a problem with software that doesn’t support non-PA setups at all. > If someone wants to use or get rid of PA on a Debian system he > probably tries to do so with the package manager first anyway. So > what's the big problem in provide multiple versions of the packages in > question -- one with and one without PA support? It’s not as simple, but we can manage it. Here, managing it will imply reverting several huge commits in g-s-d and g-media, forward-porting translations, and maintaining a different version for quite some time. I’m getting really worried to see such things happen more frequently recently. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=