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
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 attachment 30423 [details, diff] 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. ***
Diego, add what ever patches you have so they can be looked at
Created attachment 45751 [details, diff] 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 attachment 45898 [details, diff] 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 attachment 51740 [details, diff] 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.
