Bug 1066844

Please attach the log files from /tmp (or from /var/log/anaconda in the installed system), in particular anaconda.log and packaging.log

Created attachment 865319 [details]
anaconda.log

Created attachment 865321 [details]
anaconda.packaging.log

It is being installed for unoconv, which is a mandatory part of GNOME in comps.

This is part of gnome-documents' requirement chain.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

(In reply to Brian Lane from comment #5)
> It is being installed for unoconv, which is a mandatory part of GNOME in
> comps.

Hi Brian,

if you can remember this from 3 years ago ;) , should this be closed/NOTABUG?

Thanks

The situation is changed from 2014 in that unoconv should be out of the picture and libreofficekit is in the picture instead. But the same outcome.

libreofficekit (subpackage in the libreoffice.spec) has manual dependencies added for libreoffice-core and libreoffice-filters

If those dependencies were removed then it should be possible to install libreofficekit without pulling in libreoffice (as it dlopens and dlsyms its runtime requirements). Though, obviously it won't work unless libreoffice happens to be installed already.

So, it probably would be possible to provide libreofficekit without libreoffice dependencies. The unknown is if libreofficekit, and/or its users (gnome-documents primarily) are ready to safely handle the runtime failures in case of libreoffice missing.

can we split the parts of libreoffice that libreofficekit doesn't need to a separate subpackage ?  Is that just the desktop files?  or more?

There isn't a way to get libreofficekit installed and have it able to load/render documents without the current requires. We can't e.g. further finely split out the import filters without bringing along the core applications.

But it is possible for us to drop those requires and then if libreoffice is installed gnome-documents will be able to render them, and if its not installed, libreofficekit should be ok with that and just return inability to load/render.

Let me test locally if gnome-documents would survive with libreofficekit installed and without libreoffice

Yeah, testing locally it seems that gnome-documents will just not open the documents if libreofficekit is installed and libreoffice it not. No crashes, no indications at all actually. So that option is available to us if we want to pursue it.

So there are a few options I can think of:

1) keep status quo, libreoffice gets installed by default
2) install libreoffice by default but don't install the desktop files. so it's installed but you don't see it in the menus, you can view libreoffice documents via gnome-documents, but you can't open libreoffice via nautilus
3) do what's proposed in comment 16, make gnome-documents silently fail when double clicking on office documents until the user manually install libreoffice
4) add some packagekit-foo to libreofficekit to make it install libreoffice on demand when the user double clicks if they so desire?

Do those sound about right?  Caolan, is your preference 1, 2, 3 or 4 ?

(In reply to Ray Strode [halfline] from comment #18)
> So there are a few options I can think of:
> 
> 1) keep status quo, libreoffice gets installed by default
> 2) install libreoffice by default but don't install the desktop files. so
> it's installed but you don't see it in the menus, you can view libreoffice
> documents via gnome-documents, but you can't open libreoffice via nautilus
> 3) do what's proposed in comment 16, make gnome-documents silently fail when
> double clicking on office documents until the user manually install
> libreoffice
> 4) add some packagekit-foo to libreofficekit to make it install libreoffice
> on demand when the user double clicks if they so desire?
> 
> Do those sound about right?  Caolan, is your preference 1, 2, 3 or 4 ?

I would add 
5) remove LO and gnome-documents from Client variant

Btw there is at least one bug regarding 3). @mkrajnak please link it here.

I think behaviour of these two are pretty related to 3) note that both cases affects only documents which are password protected.

bug 959384 - gnome documents are unable to print password protected documents
bug 959359 - gnome documents are unable to open/render password protected documents

adding:

bug 1466164 - office documents are not rendering because of missing dependencies from libreoffice

I'd go with comment #16, just dropping the requirement of libreofficekit on libreoffice. I did that in fedora since Mar 29 2018 without any complaint there. Stuff won't work without libreoffice installed, but somethings got to give somewhere

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:2130