I'm running an Xfce system without konqueror installed, and so I do not have kfmclient. Both kipi-plugins (the export to flickr tool) and kflickr use kfmclient to start up the web browser as is necessary for flickr authentication, but of course this fails without konqueror installed. Adding konqueror as a dependency to kflickr and kipi-plugins just because one little part of it is required seems a bit over the top though (konqueror has a lot of dependencies e.g. kicker), so maybe kfmclient be turned into a separate ebuild? emerge --info Portage 2.1_rc4-r4 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r3, 2.6.15-gentoo-r1-2 i686) ================================================================= System uname: 2.6.15-gentoo-r1-2 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.6.14 ccache version 2.3 [enabled] dev-lang/python: 2.3.5-r2, 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks fixpackages metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://mirrors.blueyonder.co.uk/mirrors/gentoo ftp://ftp.mirrorservice.org/sites/www.ibiblio.org/gentoo" LINGUAS="en_GB" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/portage/xgl-coffee" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aac ace acpi alsa avi berkdb bitmap-fonts bzip2 cairo canvas cli crypt cups dbus divx4linux dri dvd dvdr dvdread dvi emboss encode faxonly ffmpeg foomaticdb gdbm gif gimpprint glitz gpm gstreamer gtk gtk2 hal icc imlib isdnlog jpeg libg++ libwww logrotate mad mikmod mmx mmxext motif mozdevelop mozilla mozsvg mp3 mpeg ncurses nls nptl nptlonly nsplugin ogg opengl pam pcre pdflib perl pic png ppds pppd python qt quicktime rar readline real reflection samba sdl session spell spl sse sse2 ssl startup-notification svg tcpd thumbnail tiff truetype truetype-fonts type1-fonts udev vorbis win32codecs wma wmf wxgtk1 x86 xml xorg xv zlib elibc_glibc input_devices_kbd input_devices_keyboard input_devices_mouse kernel_linux linguas_en_GB userland_GNU video_cards_fglrx" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Creating a kfmclient ebuild wouldn't help. As it calls Konqueror for its operations we'd had to add Konqueror as PDEPEND. Well, this bug sat long enough to let the developers of said applications use the http kio slave, so it isn't an issue anymore.
Actually I was wrong on this one. The call is deep in the innards of kdelibs...
(In reply to comment #2) > Actually I was wrong on this one. The call is deep in the innards of kdelibs... > Yeah I wondered. I'm currently on 0.1.2 and it needs kfmclient. It's a bit annoying, because AFAIK it could use exo-open instead of kfmclient.
Well, did a simple grep for kfmclient first, but then decided to look what's going on. Unfortunately it isn't as trivial as opening an executable. Application::invokeBrowser() is called, which in turn runs kfmclient, so kde-base/konqueror should probably a PDEPEND on kdelibs. I can hear Konqueror-haters and users of other desktops hear howling already...
(In reply to comment #4) > Well, did a simple grep for kfmclient first, but then decided to look what's > going on. Unfortunately it isn't as trivial as opening an executable. > Application::invokeBrowser() is called, which in turn runs kfmclient, so > kde-base/konqueror should probably a PDEPEND on kdelibs. I can hear > Konqueror-haters and users of other desktops hear howling already... > I know - but it might raise awareness and encourage the kipi-plugins devs to change the dependency. I notice kflickr no longer requires kfmclient.
Uh, I certainly don't want kipi-plugins depending on konqueror, that's just completely whacky; I have zero use for konqueror. Did anyone file this issue upstream so that kfmclient is replaced with something sane?
Jakub, read my above comment. This isn't an issue with just these two applications, but a few functions in kdelibs depending at runtime on kfmclient, which interdependents with Konqueror. No, this won't ever be fixed in KDE 3 and while it ought to be fixed in KDE 4, there is still one occurence in kdelibs 4 trunk, so if no one steps up to fix the last issue, it'll even live on at least in KDE 4.0. If you care about it, exhale loudly and vote on https://bugs.kde.org/show_bug.cgi?id=83178 Even though I'm for sure getting flak for it, I'll fix this in the next kdelibs revision. Anyone not wanting Konqueror can use /etc/portage/package.provided.
perhaps this should be marked as fixed? as kdelibs-3.5.8-r3 and kdelibs-3.5.7-r3 do NOT PDepend on Konqueror.
(In reply to comment #8) > perhaps this should be marked as fixed? as kdelibs-3.5.8-r3 and > kdelibs-3.5.7-r3 do NOT PDepend on Konqueror. It never has, fortunately. This bug is requesting to *add* such dependency, and should be WONTFIXed.
*** Bug 210942 has been marked as a duplicate of this bug. ***
/me notes that fixing this bug makes emerge $anysplitpackage on a fresh install impossible due to Bug 1343 - see Bug 210942 for the phun. The original bug was about media-gfx/kflickr and media-plugins/kipi-plugins so why this ended up in kdelibs instead is a complete mystery to me, it's a horrible place for || ( mono split ) dependencies. And while kde-base/konqueror might be a mandatory dependency for media-gfx/kflickr until the upstream bug gets fixed, it makes completely zero sense as a mandatory dependency in media-plugins/kipi-plugins, where we can simply add USE=flickr and delete kipiplugin_flickrexport.so before install when the flag is disabled.
I am heading over from BUG 210942. I had a couple of kde-*-3.5.8 ebuilds installed and 3.5.9 tried to pull kdebase-3.5.9 in including the mandatory Blocks. I did echo kde-base/kdebase >> /etc/portage/package.mask which helped but + || ( kde-base/kdebase:${SLOT} kde-base/konqueror:${SLOT} )" In kdelibs is pulling now in konqueror in. Are kdelibs really depending on konqueror now?
(In reply to comment #12) > Are kdelibs really depending on konqueror now? I guess reading this bug carefully would have prevented the need for the above question.
Okay sorry. I reread again this thread and realized the dependency was actually added intentionally recently to solve upstream issues. Well lets see how to solve this.
(In reply to comment #7) > Even though I'm for sure getting flak for it, I'll fix this in the next kdelibs > revision. Anyone not wanting Konqueror can use /etc/portage/package.provided. Agreed, this is in kdelibs-3.5.9, so I'm closing this bug.
(In reply to comment #15) > (In reply to comment #7) > > Even though I'm for sure getting flak for it, I'll fix this in the next kdelibs > > revision. Anyone not wanting Konqueror can use /etc/portage/package.provided. > > Agreed, this is in kdelibs-3.5.9, so I'm closing this bug. Erm... so once again: - this causes a *major* borkage for anyone who wants to install any split ebuild that depends on kdelibs on a fresh system. - how's something needed by media-gfx/kflickr and media-plugins/kipi-plugins a kdelibs dependency?!
(In reply to comment #16) > - this causes a *major* borkage for anyone who wants to install any split > ebuild that depends on kdelibs on a fresh system. Reverted for now, causes too many issues for portage users, cfr bug 1343.
Carlo, is this bug still relevant? FWIW, as we've dropped monos for 3.5.10, we could add the PDEPEND on konqueror and it shouldn't cause portage errors, but does it still make sense?
Old link to a forums thread: http://forums.gentoo.org/viewtopic-t-469274.html I've cc'ed myself on upstream bug - let's wait to see if the bug is acknowledged
Finally got some reply in upstream bug. This issue is being discussed in the kde-core-devel ml: http://lists.kde.org/?t=122710352700002&r=1&w=2 As expected, there isn't much hope of getting this fixed for 3.5, but a few alternatives are being discussed for 4.X.
This issue seems to have been fixed in trunk by the following commit: http://websvn.kde.org/?view=rev&sortby=file&revision=896218
