Bug 1065776

(In reply to Ben Boeckel from comment #0)
> Any rationale for:
> 
> * Thu Jan 30 2014 David Tardon <dtardon> - 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.

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.

*** Bug 1072418 has been marked as a duplicate of this bug. ***

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).

(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.

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.)

(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.

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.

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.

I brought this up on the desktop-list at [1].

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

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.

(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.

> 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

"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.

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.)

> 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.

(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.)