Bugzilla Bug 6920

When I emerged xtraceroute I was surprised that one of the dependencies was
esound.
I then checked if one can specify it in the USE variable.
As I have added "-esd" there, I wonder why esound gets built.

it turns out it is because of gnome-libs which are required to build
gdk-pixbuf,
which in turn is required for xtraceroute.  Now, if you have no need for
gnome-libs, then edit the gdk-pixbuf ebuild (I know, I know) and remove the
gnome-libs entry from the DEPEND list.  then emerge xtraceroute and you will
have no esound dependency any more.

what about changing the gnome-libs ebuild?

couldn't the dependency line
        >=media-sound/esound-0.2.23
be replaced by
        ?esd ( >=media-sound/esound-0.2.23 )
?

no, that doesn't work.  gnome _needs_ esd, afaik.

hmm, empirical testing shows it will work but may break


could we have esd as a default useflag?

*** Bug 7436 has been marked as a duplicate of this bug. ***

well.. any1 thoughts on this.. we kinda should test this on a box :) volunteers
? 

okay, if you want to do this, do it with the gnome 2.1.2 now, remove esd and
audiofile, place them in a esd? ( )  block instead.

since if we rebuild ony libgnomre without esd, then things like gnome-session
and any program linking to libgnome will break if not compiled.. Ie, we can't do
that nicely.

I don't think that works. Most (all?) people who upgrade to gnome 2.1.2 use it
as desktop with esd. And some libs really need it, so it gets installed anyway.
Secondly if you used 2.1.1 and upgrade, not all libs have a new version.. so you
still might have the same problem : old libs that still use esd. Other libs that
do not need it will still pick it up, so this means we should check and rewrite
a lot of ebuilds or even the gnome2 eclass for this test.

Since i have 2.1.2 mostly underway by now, i'm not willing to do that all right
now. I'll keep it in mind for 2.1.3

Now i think of it, i'm not sure its alltogether a good idea to remove esd, given
the amount of instances where it might go wrong. Altough its not needed for a
server install, is it harmful to have these 2 small builds around ?

This really should be tested on a clean install, any other gnome install will
likely have esd around and mess things up.

So much for a coherent comment ;) ideas popping up here and there :)

db fix

db fix

I do not think this issue is fixed. Or maybe it was fixed and then reappeared. 

I removed esound from my system and added -esd to my USE flags several months ago.  Today, emerge --update world failed while compiling libbonoboui. I traced the dependency to libgnome, and thought "oh, I'll just remerge libgnome and all will be fine."  Then I discovered that libgnome still has a forced dependency on esound! Following suggestions in this thread, I edited the libgnome-2.4.0.ebuild so it will actually check the esd flag.

Also note that the same issue exists in the libgnome-2.6.0 ebuild.

I solved the issue by changing the RDEPEND lines from this:

RDEPEND=">=dev-libs/glib-2.0.3
        >=gnome-base/gconf-2
        >=gnome-base/libbonobo-2
        >=gnome-base/gnome-vfs-2.5.3
        >=media-sound/esound-0.2.26
        >=media-libs/audiofile-0.2.3
        >=dev-libs/popt-1.5"

... to this:

RDEPEND=">=dev-libs/glib-2.0.3
        >=gnome-base/gconf-2
        >=gnome-base/libbonobo-2
        >=gnome-base/gnome-vfs-2.5.3
        >=dev-libs/popt-1.5
        esd? (>=media-sound/esound-0.2.26
              >=media-libs/audiofile-0.2.3 )"

And now I can emerge happily without picking up the esound virus.

FYI, esound is NOT harmless as some will suggest. It is a constant irritant on a multimedia workstation, because once you start compiling apps with esd support, loading one of those apps will start esd and block any other app that wants to access the audio drivers without going through esd. This breaks jack, ardour, hydrogen, amsynthe, pd, audacity, snd, sox, ecasound, etc...  Ironic since these are all serious audio apps, whereas the esound-using apps generally just want to "beep" and are perfectly useable without beeps.

I do agree that the "average" gnome user will probably want esound. This should be solved by making esd one of the default USE flags, not by having ebuilds override the user's USE flags.

argh, same exact issue in the libgnomeui ebuilds.

BTW, I should note that I don't even *use* gnome, nor have (or want) it installed. I just use various little apps (like gaim) that depend on sizeable chunks of the gnome libs.

Let me strongly voice my opinion here.  What is the point of USE flags if we
can't use them?

I hate that piece of sh*t esound.  It's a horrible crap pile of code and makes
awful sound on numerous sound cards because esd has NO write() error checking
on the buffers it sends to the sound card.

PLEASE release the various ebuilds with ?esd in them.  That's the whole point
of USE flags is to let ME decide how I want my system built.  Make esd a
default flag if you want.

do the works.

--- libgnomeui-2.6.0.ebuild~ 2004-04-30  4:32:27.395328632 -0400
+++ libgnomeui-2.6.0.ebuild  2004-04-30 14:34:19.604270280 -0400
@@ -15,7 +15,7 @@
 RDEPEND=">=x11-libs/gtk+-2.3.5
        >=x11-libs/pango-1.1.2
        >=dev-libs/popt-1.5
-       >=media-sound/esound-0.2.26
+       esound? ( >=media-sound/esound-0.2.26 )
        >=media-libs/audiofile-0.2.3
        >=gnome-base/gconf-1.2
        >=gnome-base/libgnome-2

not good enough.. full testing & working configure switches. not just
libgnomeui, but all of gnome core .

that's obvious :P and it's in progress.

Ok, since I don't run gnome, I can't honestly test everything.  But the gnome
programs I do have are running fine.  I rebuilt gnome stuff all without esound,
there are only three gnome packages (that I use), that were linked to libesd. 
The ebuild diff is naturally very simple.

I've been running a variety of gnome programs and they're all fine.  Do keep in
mind that you'll have to rebuild a half dozen packages.  You're also likely to
have a bunch of leftover gnome libraries from yonder days that gentoo never got
rid of - but that's for another bug entry.

Created an attachment (id=30423) [edit]
undoes esound from gnome lib ebuilds that "require" esound

This affects the gnome libraries that use libesd.  This patch does not touch
any other gnome parts such as applications or the gnome virtual itself.

This will not work as it only clobbers the DEPEND tree, not the actual
packages.  What you have done is created a situation where esd gets a silent
dependency, which is causing more damage and doesn't pass QA.

A fix like this has t omove beyond the "DEPEND" state, but also needs to handle
compile time dependencies.  the case that -has- to work -correctly- is :

user has esound installed
user sets -esd
user rebuilds foopack that has a DEPEND="esd? () "  in it.

In this case, foopack has to build without esound support, if it automatically
finds esound and adds it, it is broken.

*** Bug 72147 has been marked as a duplicate of this bug. ***

Sorry if I merge the thread only now, but I think this is a big problem.
esound dependency creates problems also on KDE, because arts silently links against libesd if it founds it, and then when removing esound also kde is broken.

I know that only changing the dependency won't help, but it's a start point.
Maybe we can patch the sources to always NOT found esd if -esd USE flag is found, as long as there isn't a configure switch to not use it.

If this can help I can take a look to make the source patches.
I don't think this bug can be said as resolved for now.

That is a bug in Arts if so happens, and should be filed in a new bug against
the arts package

Yes I know and I'm working on a patch to the ebuild to fix it, but I need a
little test before, I'll submit it tomorrow if I'm lucky.

This still doesn't make the gnome 'false' dependency on esound fixed, it should
not be installed only by installing gnome's libraries. A temporary fix could be
better than no fix at all.

*** Bug 72901 has been marked as a duplicate of this bug. ***

*** Bug 72147 has been marked as a duplicate of this bug. ***

Diego, add what ever patches you have so they can be looked at

Created an attachment (id=45751) [edit]
libgnome-2.8.0-noesd.patch

I submit the patch I worked on, but still not tested (as I said on bug #72901,
I haven't had the time to work on this before, and I don't wanted to re-emerge
esd on my main system).

As I said, it's not tested, but I'm confident in it.
The problem is the dependency on audiofile I wanted to investigate more on.

HTH

you should always patch configure.in to get it adopted upstream, not configure.

Anyway this is still not what we want to see, this patch just hardcodes not including the esound lib. We'd like to see a real configure check please.

I patched both to be included in ebuild.
And yes, I know a configure check should be better, for that I said it's not complete.

Created an attachment (id=45898) [edit]
libgnome-2.8.0-esdcheck.patch

Ok this time there's the --without-esound (and --without-audiofile, 'cause I
was there and adding a second check was a simple copy-and-paste stuff)
parameter is there.
I'll submit an ebuild ASAP.

Created an attachment (id=51740) [edit]
configure.in patch to disable esd dependency

I'm no more so interested in this as I was able to remove everything depending
on gnome on my system, but still this is the split-out configure.in patch.

Hope this is enough as it worked for me until I removed gnome completely.

The following ebuilds include patches to make esound an optional dependency:

libgnome-2.10.1-r1
libgnomeui-2.10.1
gnome-session-2.10.0-r2

(note that in libgnomeui, esound was entirely removed as a dependency since it's
not really required)

Please test them and let us know of any problems/suggestions you might have.

I'm currently working on reporting those patches upstream. I'm also working on
similar patches for other packages such as nautilus, control-center and
gnome-media, but those are different cases, since those packages depend
unconditionally on esound according to their sources, as opposed to having a
silent dependency on esound if it's found at compilation time. For this reason
I'll first propose the patches upstream before I do anything with them.

This package has broke on my system due a link failure against libesd despite
my -esd use flag. Linking something like gdk-pixbuf , a layer on top of X11R6
for rendering , against a cruddy sound library is absurd ! Did someone get
sloppy using defs from an include file in ESD ?

If there is some general gnome dependancy put it in a virtual ebuild of some
sort, not some ultra low-level rendering component.

please fix this absurdity so it doesn't come back.

As of 2.14.1, this is now upstream.  I'm closing this, as 2.14.1 is in portage
now.