Comment # 15 on bug 980068 from Wolfgang Bauer

(In reply to Christopher Yeleighton from comment #14)
> > > > What error message?
> > > 
> > > Cannot load libkdeinit5_khelpcenter5.so: File not found.
> > 
> > And what are you doing exactly to get that error message?
> 
> I tell Konversation to show the handbook.

As I wrote, if I do that here, I only get 
"KDEInit could not launch khelpcenter5" which actually comes from susehelp.
So sorry, I cannot reproduce this.

> > 
> > When I try to open the manual in Konversation (Help->Konversation Handbook)
> > without khelpcenter5 installed, I get this:
> > KDEInit could not launch khelpcenter5
> > (no reference at all to libkdeinit5_khelpcenter5.so or konversation trying
> > to load it)
> 
> Me too, but this message comes later.

Not here.

Just to be clear: I do agree with you in that point that if somebody needs a
library, it should require it on a package level. Whether that is figured out
by rpmbuild automatically (which is when it is linked in at "load-time"), or we
add a manual dependency (necessary if it is loaded at run-time) is secondary
though.

But we'd need to know *what* something loads it. And I don't see anything
except khelpcenter5.

Although, if we install khelpcenter5 by default, libkdeinit5_khelpcenter5.so
will be installed as well anyway.

> > And that's coming from susehelp, when it tries to run khelpcenter5.
> > As I already wrote twice, uninstalling susehelp should make Frameworks open
> > a web browser as fallback (and would also get rid of this error message).
> > Why don't you at least try that if you don't believe me?
> 
> I am more interested in KDE handbook being broken in Leap than not working
> on my workstation, otherwise I would just install khelpcenter5.

But you seem to not want to believe me.
So uninstall susehelp as a test, and you will see that the web browser shows up
instead.

> > And even if konversation or the Frameworks would load
> > libkdeinit5_khelpcenter5.so on runtime, it would be much easier to just add
> > a package dependency manually than patching the code to load it on
> > "load-time" instead. (And actually you claimed yourself that the upstream
> > code should open a web browser if libkdeinit5_khelpcenter5.so cannot be
> > found, so this should not be necessary at all then anyway...)
> 
> I got the impression that khelpcenter5 is required on Leap from what you
> said, and if it is required, there is no point in deferring loading the
> library.  Adding a dependency manually would be inappropriate in this
> situation.

It is not "required" really, at least not more than upstream requires it.

I try to explain the situation again:
- KDE Frameworks check whether the executable "khelpcenter" exists. If it does,
it gets started, if not a web browser is run instead.
- We patch KDE Frameworks to use susehelp instead of khelpcenter. So in our
case, KDE Frameworks check whether the executable (script) "susehelp" exists.
If it does, it gets started, if not a web browser is run instead.
- susehelp tries to find out on which desktop it runs. In a Plasma5 session, it
basically just runs khelpcenter5.

The problem now (on a standard installation) is that susehelp is installed by
default, but khelpcenter5 isn't.

So KDE Frameworks do not fall back to a web browser, because susehelp is there.
But susehelp cannot run khelpcenter5 (because it isn't installed), and has no
fallback, so it fails to open any documentation.

I hope the problem is finally clear now.

> But I understand that you have backed off now (in comment #9), so perhaps I
> can withdraw this suggestion too.

I have not "backed off" at all, from what anyway?

I still am of the opinion that *nothing at all* loads that library, except
khelpcenter5 itself.

Actually I was already suggesting improvements to susehelp in comment#1 (as
mentioned, falling back to the KDE4 khelpcenter won't work unfortunately
though), opening a web browser (like KDE Frameworks do) if the help application
cannot be run would be an option too.

> > You're just totally overcomplicating (and maybe misunderstanding) things
> > here.
> 
> Maybe I am, but we are failing to provide a decent product to the user,
> which is much more serious :-(

And?
This will be fixed by installing khelpcenter5 by default.
We will then have the same situation as we had in previous releases (with KDE4)
for years.

The difference here is basically just that the KDE4 khelpcenter always was
installed by default, it is in the package kdebase4-runtime which is pulled in
by basically any KDE4 application. Now we'd need khelpcenter5 (which is in a
separate package), but so far nobody thought of making sure it is installed.

This whole (IMHO pointless) "discussion" has already wasted far more time than
actually fixing the problem would have taken...