Sound "Automatic" preference should be in both the Sound Preferences menu and config file even if gstreamer is not available. If gstreamer is not available, it should use the command specified by the distro package in a standard location like /etc/gaim/play-command. This config file is to be optional, like the other optional file /etc/gaim/prefs.xml. Benefits of this Approach: - Both new and existing user profiles work with sound output on RHEL3 and RHEL4 which lack gstreamer-0.10. Older distros may explicitly specify a desired play command. - No manual configuration is needed by users.
What if you guys changed your /etc/gaim/prefs.xml to set the sound preference to "Custom" and the command to [whatever]. I guess existing profiles wouldn't work? The change you suggest doesn't have a lot of appeal to me... So you're going to put Gaim 2.0.0 into RHEL3 and RHEL4, but you're not going to upgrade to gstreamer-0.10? I'd like to hear from other Gaim developers on this, but it seems to me that a Red Hat-specific patch to fix this issue might be a cleaner solution (from our point of view).
We understand why upstream gave up entirely on libao because of how bad it is. But you are gravely underestimating the amount of grief and bitching leaving no automatic sound fallback option will cause to users. - It is unacceptable for sound to seize working after an upgrade. - It is unacceptable to expect users to change a preference manually to get it to work again. - It is infeasible to expect a "stable" Enterprise release to add or upgrade gstreamer. - Setting the Custom option in /etc/gaim/prefs.xml is insufficient because of existing user profiles. Will removal of libao with no automatic fallback truly be a Red Hat specific problem? I don't think so. We really don't want to stray from upstream for the long-term. It would be very sub-optimal for us to maintain a Red Hat specific patch into the next five years.
While I'm not at all opposed to an automatic fallback, I *do* believe that this will be primarily a redhat/fedora problem. Debian doesn't upgrade packages after declaring a release stable. Ubuntu seems to do so only very rarely, and in fact has rejected several requests to upgrade the gaim package after having declared edgy frozen. Suse already patches gaim quite heavily, so though I do not know with any specificity their policy on upgrades after release, I doubt that they will bulk at patching. I rarely hear from mandriva users, though mandrake was at one point quite popular. Gentoo users will upgrade gstreamer with gaim, and most if not all other distributions (Centos excluded as it falls under the category of "Redhat" for my purposes) have a comparatively trivial user base.
We feel it counter-productive to pretend that older versions of gaim remain useful. It is expensive in engineering resources to maintain increasingly larger deltas over the +5 years. Increasing expense of maintenance combined with decreasing usefulness of older versions is a good reason for us to do the exact oppsite of SuSE. We have a small set of packages in RHEL that are upgraded to latest upstream versions often. Requirements for these packages include: 1) Must adapt to hostile arbitrary changes on the Internet 2) Leaf-node in the distribution. 3) Would be difficult and expensive to maintain in the long-term without upstream's support gstreamer-0.10 does not fall into the above requirements, thus it is impossible to upgrade that along with gaim. I can agree that keeping libao out of gaim is a good idea, but we would really like an official "Automatic" distro-defined command fallback in upstream so we don't have to maintain any deltas for the years to come.
Currently when Gaim isn't compiled against gstreamer we just do a gdk_beep() where we would normally play a sound. How do you feel about a patch for your RPM that would exec a hard-coded sound command? Something like /etc/alternatives/playsound?
> How do you feel about a patch for your RPM that would exec a hard-coded sound > command? Something like /etc/alternatives/playsound? Proposed Logic ============== 1) Preserve the "Automatic" preference, requiring no user intervention. 2) If Automatic with no gstreamer, If /etc/alternatives/playsound exists, Then use it. 3) If /etc/alternatives/playsound does not exist, then gdk_beep. Patching our RPM to do this would be fine. However given this simple logic, why not make this the default in upstream too? This is currently the only difference between upstream and Fedora gaim.
On second thought, I would prefer that we avoid using alternatives for this and instead use a hard-coded location for an optional script, something like /etc/gaim/playsound. But the concept is the same.
I think I'd be ok with putting something like this into upstream Gaim. How do other Gaim devs feel? Is /etc/alternatives standardized in any way? Or is it distribution-specific? I guess there's no existing command in /etc/alternatives to play a sound?
I mentioned in #gaim that I was hoping to find some time to do some more generic "intelligent" migration of sound preferences for older distros that don't have any chance of getting gstreamer support, but I'm not able to commit to anything. I'd be happy to see a basic fallback on something distributions can relatively easily specify if (as is unfortunately likely) I don't get around to doing anything better. On the subject of /etc/alternatives vs. a gaim specific path, I think alternatives is too overloaded and non-standardized for what is required here, but that might be best determined on the gaim-packagers mailing list.
The usual purpose of alternatives is for a standard command line tool (like sendmail) to provide a means to replace that functionality with an entirely different program in an interchangable way. Unfortunately, using alternatives with a packaging system like RPM is INCREDIBLY UGLY AND COMPLICATED involving all kinds of scriptlets and worse, triggers. We can achieve the same effect with a hard-coded optional script location. RPM %config(noreplace) on this script would be ideal and simple. If you do find a better way to intelligently handle non-gstreamer, I would prefer that though. But at least we have a known good fallback if the team is unable to implement anything before release.
I'm not sure why it would be a problem to add gstreamer010 packages to RHEL3/4 to begin with, given that they're compatible with the 0.8 packages on those machines. Also confusing to see that it's ok to upgrade gaim (which IMO has gotten worse, not better) but not something else. What makes gaim so special that it would get special treatment for HREL3/4 ?
We had been upgrading gaim to the latest upstream "stable" versions in RHEL3 and RHEL4 because it older versions become far less functional, and it becomes more and more difficult to backport security fixes over time. The new decision however is for RHEL3 and RHEL4 to remain at 1.5.x. pidign-1.5.x maintenance branch will be maintained for a while for distros like us.