Bugzilla Bug 136087

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