Description of problem: stringent package depending from zeigeist package, although this package is not an important part of KDE or system Version-Release number of selected component (if applicable): libzeitgeist-0.3.18-1.fc17 How reproducible: # LANG=C yum remove zeitgeist* Steps to Reproduce: 1. 2. 3. Actual results: .......... Remove 2 Packages (+185 Dependent packages) Installed size: 688 M Is this ok [y/N]: n ......... this command remove all KDE + some other applications Expected results: .......... Remove 2 Packages .......... Additional info:
Version-Release number of selected component (if applicable): libqzeitgeist-0.8.0-6.fc17
libzeitgeist <- phonon <- kdelibs. Reassigning to phonon.
Zeitgeist support in phonon is currently not optional at runtime, it's either enabled at build-time ... or not. We've chosen to enable it.
If I understand correctly, that the libqzeitgeist library needed to build and work, but not the zeitgeist daemon from the zeitgeist* packages. These zeitgeist* packages can be excluded from the dependency?
In fact, if you do not run zeitgeist daemon, KDE continues to work as usual. Therefore, depending on the rigid zeitgeist daemon should not be. (zeitgeist daemon is not itself a necessary element of KDE.)
If rpm/yum supported some notion of soft dependencies, yes, that could be an option. but they don't. So, we have a choice to make, either enable zeitgeist and include the necessary (hard) dependencies for the feature to actually work... or not. We've chosen the former.
It's very strange that the library can not exist without the demon who uses this same library. Perhaps libqzeitgeist library necessary in build phonon, but runned zeitgeist daemon in build and work? -- unbelievable ..
** but runned zeitgeist daemon in build and work Phonon?
It's not that libqzeitgeist cannot technically exist without zeitgeist, it's that zeitgeist is necessary for libqzeitgeist to actually be functional. Whether the zeitgeist daemon is run at build time or not is entirely irrelevant, it is not used at build time, it is a runtime-only dependency. (But RPM does not support these either, so in fact the daemon will be dragged into the build chroots too. But that doesn't hurt.)
IMHO This is the confusion and complexity to be solved ... Although this situation is not painful, but it is not reasonable. It is difficult to convey part of the code needed for both packages to the library? Or, if the library can not function normally without runned zeitgeist service, it is difficult to write a "cap"? And now it turns out that all of KDE depends on the service, which in itself is not essential for KDE. And remove it from startup can only manually (though not all will find where to do it), or write a script that kills the process after loading KDE. It's a stupid situation.
Feel free to contact the zeitgeist package maintainer(s) with your ideas on how to make the backend daemon optional, yet "just work" for everyone else. (I've yet to see any constructive suggestions on how to implement that beyond just restating that you don't like it).
I think there is a working solution, which at this point will satisfy everyone. To do this, remove the dependency of the libqzeitgeist packet from the zeitgeist package and add zeitgeist package to the "@kde-desktop" group. Thus, zeitgeist package will be installed with KDE, but anyone can safely remove it (because disabling it is not possible to graphically). It will respect the freedom of users, but will not be deprived of planned functionality by default.
P.S. I have written here, because I think that the initiator of the request about inclusion the zeitgeist package to the @kde-desktop group should be done by maintainer of libqzeitgeist.
<strike>should be done by maintainer of libqzeitgeist</strike> should be the maintainer of libqzeitgeist
Not acceptable to me. there are a multitude of ways to end up with libqzeitgeist getting installed besides using @kde-desktop group Besides, in order to even consider doing this, we need a good use-case (besides just "I don't want zeitgeist"). Please take this to devel@fpo or kde@fpo mailing list for discussion (using bugzilla for discussion is not practical)