Bug 212247 - gaim needs "Automatic" sound fallback to /etc/gaim/play-command
Summary: gaim needs "Automatic" sound fallback to /etc/gaim/play-command
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gaim
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Warren Togami
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-10-25 20:19 UTC by Warren Togami
Modified: 2007-11-30 22:11 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-04-17 17:38:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Warren Togami 2006-10-25 20:19:08 UTC
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.

Comment 1 Mark Doliner 2006-10-30 05:17:39 UTC
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).

Comment 2 Warren Togami 2006-10-30 12:29:49 UTC
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.

Comment 3 Luke Schierer 2006-10-30 14:23:23 UTC
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. 

Comment 4 Warren Togami 2006-10-30 20:05:28 UTC
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.

Comment 5 Mark Doliner 2006-11-07 07:46:42 UTC
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?

Comment 6 Warren Togami 2006-11-08 22:55:28 UTC
> 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.

Comment 7 Warren Togami 2006-11-08 22:58:27 UTC
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.


Comment 8 Mark Doliner 2006-11-09 02:30:05 UTC
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?

Comment 9 Stu Tomlinson 2006-11-09 03:11:28 UTC
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.

Comment 10 Warren Togami 2006-11-09 03:41:07 UTC
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.

Comment 11 Thomas Vander Stichele 2007-04-11 12:34:18 UTC
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 ?

Comment 12 Warren Togami 2007-04-11 15:09:38 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.