Version: (using KDE KDE 3.4.0) Installed from: Gentoo Packages kdebase/kioslave/media/mounthelper depends on the kdeeject script and therefore on kdesktop. I'd like to see this dependency going away. If kdesktop is not installed, the 'dcop kdesktop' call would just silently fail, but it would be possible to have konqueror with the kdebase kioslaves installed without kdesktop and it's dependencies.
Ask your packagers. We provide kdebase as one big kdebase tarball, the splitting is up to be done by packagers. From a sources point of view it makes no difference where inside kdebase the kdeeject script is.
Well, I am the packager in this case and of course it can be done on our side. It's just that this is one simple fix for you, while I have to add a few lines of code to two ebuilds here. Regarding the "sources point of view": I do not consider it clean to have such interdependencies unnecessarily. For a source distribution like Gentoo such hidden dependencies are a pain. It's true, that you can apply the usual big tarball argument, but it doesn't harm to be nice. :)
Well if I move it in the sources (which I can't do before the switch to svn, but that's another story), it would break for every other packager who splits up the sources (debian etc.), won't it? :) Being nice also includes not doing a fix for one person which breaks things for 10 others :) Although I guess that people making binary packages just install all of kdebase and split up the result, whereas you split the stuff right in the sources? I had another look: the reason it was in kdesktop was that it was only used by the "Create new..." templates which are there too. But now that kio_media uses it too, I guess a logical place for kdeeject would be kdebase/libkonq, or its own subdir in kdebase (which would be a good idea if it one day turns into a C++ program).
>before the switch to svn Hopefully it doens't take that long. The unusable web{cvs,svn}.kde.org isn't fun. > Being nice also includes not doing a fix for one person which breaks things for 10 others :) Maybe, but you have to admit that it would be more correct for everyone who splits the tarballs. And I'm sure they'll figure it out very fast. >whereas you split the stuff right in the sources? Almost everything that can be split. More than 300 ebuilds. kdeaddons is handled a bit more restrictive, e.g. konqueror-plugins, than an ebuild for every single one, as we had in the first place. At least for KDE 3.4 we provide ebuilds for the kde.org tarballs as well. So a user can decide e.g. to build only kmail and kcachegrind and the ebuilds pull in all necessary dependencies. Optional dependencies can en/disabled via "use flags" (e.g. samba or arts support). That's another thing we have an ongoing fight with, btw. - autodetection of optional dependencies are poison for a software management system like Portage. Determinism via --enable-foo switches is crucial. >I guess a logical place for kdeeject would be kdebase/libkonq I agree. Should have proposed that in the first place.
Um, on a second thought libkonq isn't a good place at all. There are lots of apps which (can) use kdebase kioslaves, but don't need libkonq (or kdesktop). I still favor kdialog, since it is the only app needed by the script to provide user feedback, has no other dependencies and is therefore unproblematic.
Putting kdeeject in kdialog/ doesn't make sense, since users might not realize that they need kdialog in order to be able to eject CDROMs. kdialog is a dependency of kdeeject, but kdeeject itself is a dependency of kdesktop and kio_media. No, I think I'll just make it a subdir of its own, since the long term plan is to turn it into a C++ application anyway [in which case it won't depend on kdialog anymore, hehe].
>Putting kdeeject in kdialog/ doesn't make sense, since users might not realize that they need kdialog in order to be able to eject CDROMs. They don't have to - it's the job of the packager to make sure the correct dependencies are pulled in. And since the script needs kdialog at runtime, each packager has this runtime dependency set anyways. Otherwise it's a packaging bug. This is the case right now and won't change. Only the hard depenency on kdesktop goes away. Of course a subdir of it's own is fine, too.
Any chance to change this for KDE 3.4.2? :)
SVN commit 418311 by dfaure: Move kdeeject to a subdir of its own, to make gentoo packagers happy (they split kdebase in pieces, as we recommend, and mounthelper depends on kdeeject, but shouldn't depend on kdesktop). It also makes sense because one day kdeeject might/should become a C++ program instead of a shellscript. BUG: 104393 A kdeeject (directory) A kdeeject/kdeeject kdesktop/kdeeject#418308 M +0 -1 kdesktop/Makefile.am D kdesktop/kdeeject --- trunk/KDE/kdebase/kdesktop/Makefile.am #418310:418311 @@ -10,7 +10,6 @@ bin_PROGRAMS = kcheckrunning lib_LTLIBRARIES = -bin_SCRIPTS = kdeeject kdeinit_LTLIBRARIES = kdesktop.la noinst_LTLIBRARIES = libkdesktopsettings.la
Thank you, David.
Bug closed. Kdesktop is no more mantained.