On 29 September 2010 21:06, Richard <[email protected]> wrote: > On Wednesday 29 September 2010 07:23:28 Renaud MICHEL wrote: >> On mercredi 29 septembre 2010 at 01:47, Richard wrote : >> > Does this mean that I can find the KDE packages which "depend" on Pulse >> > and re-package them such that Pulse is only "recommended"? >> >> Here (2010.1 x86_64) KDE does not have a dependency on pulse audio. >> Gnome has, because pulseaudio (actually the package is pulseaudio-esound- >> compat) provides esound, which is required by gnome. >> > Sorry I was so careless in my comment. I was working from memory and those > memories are heavily dosed with frustration and annoyance. What I should have > done is give a concrete example. When I select lib64pulseaudio0 for removal, > rpmdrake lists 526 dependencies (direct and, presumably, indirect) which must > also be removed. > > Only 39 of these have the string "kde" in the package name, but some of these > are quite central to the operation of KDE; > > kdepasswd-4.4.3 > kdenetwork4-core-4.4.3 > kdemultimedia4-core-4.4.3 > kdegraphics4-core-4.4.3 > kdegames4-core-4.4.3 > kdeutils4-core-4.4.3 > kdelibs4-core-4.4.3 > > ...for example. > > Many many more are kde applications. This is 2010.1 x86_64
Yes, it's a bit on an indirect dependency phonon requires libpulse.so: $ urpmf --requires lib64phonon4 | grep pulse lib64phonon4:libpulse-mainloop-glib.so.0()(64bit) lib64phonon4:libpulse.so.0()(64bit) and of course removing phonon would remove many more kde4 packages. >> >> Anyway, you can simply disable pulseaudio from the control center, so it is >> not a problem to have the package still lying around. > > That is, of course, the first thing I do when installing new systems. I don't > think that I can agree that it is not a problem for me to have all of this > Pulse stuff lying around. I find it quite tricky enough to get all required > applications working as I want them without having to worry about whether > something somewhere thinks it can still use Pulse because the support files > are still present. > Don't worry, disabling pulse really disables it, the relevant config files are edited properly... etc You see the problem here, for phonon to have pulse support it must be built against it, so you can't remove libpulse.so. (that same for e.g. mplayer, to have pulse support it must be built against pulse, but disabling pulse and/or selecting another audio output driver will make it not use pulse). As misc said a couple of days ago, this is always the case when having support for a feature must be done at package compilation time, this adds a hard requires on some other packages, in this case pulse. i.e. you can't have phonon (or mplayer) use pulse otherwise. > Worse still are the applications which presume Pulse must be present and are > configured with that incorrect default assumption, but that's another gripe > for another place. > > Richard > > > Which apps? if you rpm -e --nodeps a lib package, it's logical that an binary that has a dep on that package will not work as it'll won't find it at startup, even if it's not going to really use it (mplayer example applies here too). -- Ahmad Samir
