Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1065776 - libreoffice-filters dependency is heavier
Summary: libreoffice-filters dependency is heavier
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: unoconv
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: David Tardon
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1072418 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-16 21:51 UTC by Ben Boeckel
Modified: 2014-03-07 13:57 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-16 22:37:49 UTC


Attachments (Terms of Use)
Cannot close confusing applications without confusing error message (deleted)
2014-03-05 15:23 UTC, Michael Catanzaro
no flags Details
Weird, misplaced icons (deleted)
2014-03-05 15:25 UTC, Michael Catanzaro
no flags Details

Description Ben Boeckel 2014-02-16 21:51:25 UTC
Any rationale for:

* Thu Jan 30 2014 David Tardon <dtardon@redhat.com> - 0.6-7
- pull in all libreoffice filters

? It's dragging in a pile of dependencies I don't care about.

Comment 1 David Tardon 2014-02-16 22:37:49 UTC
(In reply to Ben Boeckel from comment #0)
> Any rationale for:
> 
> * Thu Jan 30 2014 David Tardon <dtardon@redhat.com> - 0.6-7
> - pull in all libreoffice filters
> 
> ? It's dragging in a pile of dependencies I don't care about.

Yes. It turns out that people actually want to use unoconv to convert documents, for which they need the import (and export) filters. Which are scattered across a pile of libraries.

Note1: I would be happy to replace the Requires by Recommends, as soon as rpm implements that.

Note2: Before you start shouting about wasted disk space and what not, you should realize that libreoffice-core is much bigger than the rest of libreoffice- packages combined (including the newly pulled import filter libraries).

Note3: libreoffice-pyuno (required by unoconv) has gained dependency on libreoffice-writer already in 4.0.x (nearly a year ago), without anyone protesting. The dependency was not really required: all that was needed was to split librelogo to a separate subpackage.

Comment 2 Ben Boeckel 2014-02-16 23:51:28 UTC
I was more curious (looked for bug references). Plus, I'm not so worried about disk space, but bandwidth issues from more packages to update (and these Requires chains tend to only grow over time).

I didn't notice the -writer dependency since that's the one I usually use unoconv for.

Comment 3 David Tardon 2014-03-04 16:47:02 UTC
*** Bug 1072418 has been marked as a duplicate of this bug. ***

Comment 4 Ben Boeckel 2014-03-04 17:59:06 UTC
FWIW, there used to be split packages of the actual functionality unoconv required from the GUI bits. I don't know how much work that would involve though (ISTR the merge happening when we were still using OOo).

Comment 5 David Tardon 2014-03-04 20:33:29 UTC
(In reply to Ben Boeckel from comment #4)
> FWIW, there used to be split packages of the actual functionality unoconv
> required from the GUI bits. I don't know how much work that would involve
> though (ISTR the merge happening when we were still using OOo).

The split existed only because there were two sets of applications: openoffice.org and broffice.org (I have mercifully forgotten what was the difference between them). And it most definitely was not split of "the GUI bits" from the rest. The openoffice.org-foo and broffice.org-foo packages (where foo is calc, writer, etc.) only contained the desktop file and script to run the tool in question (/usr/bin/oocalc etc.) Everything else (including all Requires) was already in openoffice.org-foo-core packages. When LibreOffice upstream dropped broffice, there was no further need to maintain that split.

Comment 6 Michael Catanzaro 2014-03-05 00:52:04 UTC
Hey David, would it be possible to revert this change (preferably ASAP) in F20? Adding a dependency (albeit indirect) on strange graphical applications in a stable release is a very serious issue. In rawhide, at least we have some time to evaluate what to do about this without disrupting more users. 

unoconv depending on anything graphical is very bad for the desktop team. GNOME uses unoconv for both gnome-documents and sushi and it really cannot depend on LibreOffice programs, strange Java logging utilities (Chainsaw and LogFactor5), or database management systems. (A Recommends as implemented by other distributions would be equally bad, since Recommends get installed by default.)

Comment 7 David Tardon 2014-03-05 07:42:18 UTC
(In reply to Michael Catanzaro from comment #6)
> Hey David, would it be possible to revert this change (preferably ASAP) in
> F20?

No, it would not. The change has been made for a reason.

> Adding a dependency (albeit indirect) on strange graphical applications
> in a stable release is a very serious issue.

I do not see why.

> unoconv depending on anything graphical is very bad for the desktop team.

Why?

> GNOME uses unoconv for both gnome-documents and sushi and it really cannot
> depend on LibreOffice programs,

That is where you are wrong. gnome-documents uses unoconv specifically to convert files to PDF (or ODF? I forget.) to display previews. To do that, unoconv needs the import filters. These are in the respective libreoffice packages. Therefore, the libreoffice packages must be installed.

Comment 8 Michael Catanzaro 2014-03-05 15:23:52 UTC
Created attachment 871034 [details]
Cannot close confusing applications without confusing error message

I understand that unoconv requires filters from the some LibreOffice package. Surely those filters don't really depend on the GUI applications and can be split into a subpackage?

If it's really impossible to do that split, then it's not a huge problem that unoconv depends on packages already present in Fedora Desktop (Writer, Impress, Calc, Draw), but I *absolutely* cannot imagine that unoconv requires LibreOffice Base, which is purposefully not included. Why do we need a database management application to display a ODT file? postrgresql? Or these strange applications with 1990s graphics. I cannot even close this one without a confusing warning message. (A nontechnical user won't know what a virtual machine is, and anyone unfamiliar with Java will be confused by Swing.)

I hope you can understand why I consider this to be a big problem.

Comment 9 Michael Catanzaro 2014-03-05 15:25:08 UTC
Created attachment 871036 [details]
Weird, misplaced icons

These applications have strange icons that are clearly out of place in GNOME. They don't belong in Fedora Desktop.

Comment 10 Michael Catanzaro 2014-03-05 15:37:03 UTC
I brought this up on the desktop-list at [1].

[1] https://lists.fedoraproject.org/pipermail/desktop/2014-March/009459.html

Comment 11 Caolan McNamara 2014-03-05 15:41:05 UTC
caolanm->michael: I think the real problem here is that apache-commons-logging requires log4j and log4j is the package providing those programs, its not "LibreOffice requires log4j"

Sounds to me that the right solution is a bug against log4j to split that into two subpackages, one that provides the log4j.jar and one for the UI applications.

Comment 12 David Tardon 2014-03-05 17:24:58 UTC
(In reply to Michael Catanzaro from comment #8)
> Created attachment 871034 [details]
> Cannot close confusing applications without confusing error message
> 
> I understand that unoconv requires filters from the some LibreOffice
> package. Surely those filters don't really depend on the GUI applications
> and can be split into a subpackage?

There are no separate GUI applications. The launch scripts only call the main executable with the right option. I can split them and the desktop files into separate packages, but that will not change the dependencies in any way.

> 
> If it's really impossible to do that split, then it's not a huge problem
> that unoconv depends on packages already present in Fedora Desktop (Writer,
> Impress, Calc, Draw), but I *absolutely* cannot imagine that unoconv
> requires LibreOffice Base, which is purposefully not included. Why do we
> need a database management application to display a ODT file?

unoconv does not _display_ anything. It converts files from one supported format to another. But I see that Base does not actually support anything but ODB. I will remove it from the dependecies.

> Or these strange applications with 1990s graphics. I cannot even close this
> one without a confusing warning message. (A nontechnical user won't know
> what a virtual machine is, and anyone unfamiliar with Java will be confused
> by Swing.)

Why? Nontechnical users use MS Windows, where each application looks different anyway.

Comment 13 Michael Catanzaro 2014-03-06 00:07:05 UTC
> unoconv does not _display_ anything. It converts files from one supported
> format to another. But I see that Base does not actually support anything
> but ODB. I will remove it from the dependecies.

Great, thanks! I think that in itself is enough to resolve the immediate problem in F20. (Secondarily, that eliminates the huge unwanted dependency chain. :)

Going forward...

(In reply to Caolan McNamara from comment #11)
> caolanm->michael: I think the real problem here is that
> apache-commons-logging requires log4j and log4j is the package providing
> those programs, its not "LibreOffice requires log4j"
> 
> Sounds to me that the right solution is a bug against log4j to split that
> into two subpackages, one that provides the log4j.jar and one for the UI
> applications.

This particular package came up on devel@ recently and the maintainer was hesitant to do so [1], but I agree that's the correct solution to the problem "LO Base depends on weird logging utilities."

One big new rule that's made its way into the Workstation technical specification (but I'm not sure if it's in the packaging guidelines yet) is that applications aren't allowed to depend on other applications, and indirect dependencies are just as bad as direct dependencies. This is not as big a deal, but it is a problem and the solution is blacklisting the offending app from the software installer. (Richard says it would be log4j, but I think it should be Base, since installing Base is what would bring in unexpected dependencies, while installing log4j causes no problems.) Regardless, nobody wants that.

(In reply to David Tardon from comment #12) 
> There are no separate GUI applications. The launch scripts only call the
> main executable with the right option. I can split them and the desktop
> files into separate packages, but that will not change the dependencies in
> any way.

That might actually be best, since that eliminates unoconv's dependency on any applications, using the definition "application = appdata + desktop file." Even if LO is still installed with unoconv, the user is not disturbed as long as no new desktop files appear.

Admittedly, that is a bit odd, but that solution fits best with the new expectations for applications. The extension of "applications cannot depend on applications" is that all applications are expected to be leaf packages. I don't think this is specified anywhere currently, and I don't know if anybody is going to make a stink about unoconv depending on LO programs that are installed by default. But if unoconv were to depend on everything except the desktop files, it would be kosher for sure.

[1] https://lists.fedoraproject.org/pipermail/devel/2014-January/194952.html

Comment 14 Caolan McNamara 2014-03-06 16:34:37 UTC
"I think it should be Base, since installing Base is what would bring in unexpected dependencies, while installing log4j causes no problems" doesn't sounds right to me because base does not depend on log4j directly and has no control over what its dependencies themselves depend on. e.g. if libstdc++  installed a graphical utility then libstdc++ would get fixed not blacklist everything that depends on libstdc++. I never even *heard* of log4j before this discussion because it's so far down the dependency stack.

Comment 15 Michael Catanzaro 2014-03-07 00:15:45 UTC
But there's a distinction between what package is at fault (log4j for not providing subpackages; or apache-commons-logging, for depending on an application) and actually fixing the broken user experience. log4j would be the right application to blacklist if the goal is to punish packagers for not using subpackages, but that would not actually accomplish anything. In contrast, if Base were to disappear, then the problem would be gone. (Again, that would be a terrible resolution, but IMO better than the status quo.)

Comment 16 David Tardon 2014-03-07 06:35:00 UTC
> One big new rule that's made its way into the Workstation technical
> specification (but I'm not sure if it's in the packaging guidelines yet) is
> that applications aren't allowed to depend on other applications

Btw, I have yet to see that "rule" in any official documentation. Or even mentioned on fedora-devel. (No, I did not read the technical specification. Just like, I suspect, most of the other packagers). In any case, there is no "Workstation product" in F-20, so it has no applicability there.

Comment 17 Michael Catanzaro 2014-03-07 13:57:15 UTC
(In reply to David Tardon from comment #16)
> Btw, I have yet to see that "rule" in any official documentation. Or even
> mentioned on fedora-devel. (No, I did not read the technical specification.
> Just like, I suspect, most of the other packagers).

It's here: https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications

> In any case, there is no
> "Workstation product" in F-20, so it has no applicability there.

Yup. (And the technical specification is still a WIP, too.)


Note You need to log in before you can comment on or make changes to this bug.