Re: Bug#170843: status of patch
On Sat, 2002-12-14 at 04:10, Chipzz wrote:
> On Thu, 12 Dec 2002, Steve Greenland wrote:
>
> > From: Steve Greenland <steveg@moregruel.net>
> > Subject: Re: Bug#170843: status of patch
> >
> > On 11-Dec-02, 20:25 (CST), Chipzz <chipzz@ULYSSIS.Org> wrote:
> > > I think this option is horribly wrong. Why use it at all when you can
> > > start esd with
> > > 'esd `cat /etc/esound/esd.conf`'
> > > ? Another option just adds to the copmplexity and will confuse the user.
> >
> > Because not every machine is a single-user machine, and not every user
> > can edit /etc/esound/esd.conf?
>
> That is one more reason NOT to have this (~/.esd.conf) file/variable. Do
> you expect every user to tweak his own settings let alone know about this
> undocumented variable/ ~/.esd.conf ?
> If you're giving that as an argument you clearly haven't done any system
> administration (for multi-user machines) yet. I have. And the one rule
> of thumb there is: avoid settings in ~ where-ever possible, and use sys-
> tem-wide settings if possible. The rationale for that is that they can
> get out of sync, or deleted by the user, and then all of a sudden things
> mysteriously break. It is the sysadmins task to set up
> /etc/esound/esd.conf, and if he hasn't done so that may be for a good
> reason, for example not wanting the users to play sounds in the first
> place, which may be the case in case of a remote server. You just broke
> that setup.
>
The current behavior of esd is to look at ESD_SPAWN_OPTIONS,
/etc/esound/esd.conf, ~/.esd.conf, and take command line arguments. The
documentation says to use /esd/esound/esd.conf. The problem is, esd is
not consistent with how it should be configured, it only reads
/esd/esound/esd.conf and ~/.esd.conf if set to autowspawn, and
ESD_SPAWN_OPTIONS if set autospawn or launched from the command line.
Gnome launches it with g_command_line_async() without autospawning, so
esd doesn't consult anything, so gnome has to give esd its own args, but
they are currently hardcoded. This is a confusing way to configure an
application, and is largely undocumented unless you read the code (or
google).
My patch was an attempt to make esd work better for gnome users and the
idea was to put ESD_SPAWN_OPTIONS in /etc/environment, so the it would
be easy to administer. All the other stuff (~/esd.conf, etc) is only if
a user desired to do something different him or herself-- not to
administer esd generally.
> > Yes, it sounds like gnome-session should start esd with esd.conf by
> > default to obtain options that required for the card to work, but if
> > it makes sense to pass options that are user preferences, then it also
> > needs to support an environment variable or ~/.esd.conf or some such.
>
> Read above why it most definately shouldn't.
Your arguments above clearly cry out for a general config file to
administer esd-- like every time esd starts, no matter how, no matter
where, it reads everything in. This way you don't have to administer
gnome and esd and any other app that spawns esd on its own separately--
you administer esd via /etc/esound/esd.conf. My patch does not do that,
and now I am working with upstream to fix esd. I have another patch
that makes esd use /etc/esound/esd.conf as a general config file which
makes its behavior clear and consistent to the end user/administrator.
Users who need different, specific behavior get to use ~/.esd.conf and
ESD_SPAWN_OPTOPNS. esd will read it all in. I will post to the list if
anything comes of it.
Jamie
--
Email: jstrand1@rochester.rr.com
GPG/PGP ID: 26384A3A
Fingerprint: D9FF DF4A 2D46 A353 A289 E8F5 AA75 DCBE 2638 4A3A
Reply to: